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Rozdział 1 


Wprowadzenie 


Dziedziną, której dotyczy ta praca i zarazem szczególnym obszarem zainteresowań 
autora jest renderowanie akcelerowanej sprzętowo, trójwymiarowej grafiki kom¬ 
puterowej czasu rzeczywistego. Aby uściślić to określenie, warto opisać każdą jego 
część: 

• Grafika komputerowa [1] to dziedzina informatyki związana z operowaniem na 
obrazach. 

• Grafika trójwymiarowa to taka, w której obiekty reprezentowane są w prze¬ 
strzeni 3D i dopiero na koniec odzwierciedlane na płaszczyźnie ekranu. 

• Renderowanie to generowanie (wytwarzanie) obrazu na podstawie danych wej¬ 
ściowych, w odróżnieniu od przetwarzania istniejącego obrazu czy też jego anali¬ 
zowania. 

• Grafika czasu rzeczywistego wymaga, aby obraz powstawał nie dłużej niż około 
0.03 sekundy, co pozwala na pokazywanie przynajmniej 30 klatek obrazu na se¬ 
kundę i tym samym daje złudzenie płynnego ruchu oraz zapewnia interaktyw¬ 
ność. 

• Grafika akcelerowana sprzętowo to taka, w której do renderowania obrazu 
i uzyskania wydajności wymaganej do działania w czasie rzeczywistym wyko¬ 
rzystywane jest wsparcie nowoczesnych kart graficznych. 

Grafika komputerowa posiada liczne zastosowania, pośród których wymienić moż na 
projektowanie (np. inżynierskie, architektoniczne), wizualizację (np. naukową, bizne¬ 
sową), zastosowania artystyczne oraz rozrywkowe (np. filmy, gry). 

Grafika czasu rzeczywistego stanowi z punktu widzenia programisty szczególne 
wyzwanie. W grafice takiej nie można sobie pozwolić na wyliczanie obrazu dowolnymi 
metodami zapewniającymi pożądaną jakość, tak jak to jest robione w przypadku przy¬ 
gotowania współczesnych filmów animowanych. Konieczność zapewnienia dostatecz¬ 
nie krótkiego czasu powstawania obrazu wymusza zaawansowane optymalizacje, jak 
najlepsze wykorzystanie dostępnego sprzętu oraz dobór stosowanych technik i algo¬ 
rytmów, które zapewnią odpowiednią wydajność przy jak najmniejszej utracie jakości. 
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Do zastosowań grafiki komputerowej czasu rzeczywistego należą m.in. symulacje 
(służące np. do szkolenia pilotów czy żołnierzy) oraz gry komputerowe. Gry kompu¬ 
terowe. jakkolwiek służą celom rozrywkowym, muszą być przy tym brane pod uwagę 
jako bardzo poważne zastosowanie, ponieważ przemysł gier rozwija się obecnie na 
świecie bardzo szybko i osiąga obroty porównywalne z przemysłem filmowym. Ter¬ 
minu „gry komputerowe” (albo też „gry wideo”) nie należy mylić z dziedziną matema¬ 
tyki nazywaną teorią gier, gdyż są to zupełnie różne pojęcia. 

Tworzenie gier jako proces biznesowy składa się z wielu elementów i wymaga 
współpracy specjalistów wielu dziedzin takich jak programiści, graficy, muzycy, pro¬ 
jektanci, testerzy, i inni. Powstanie gry komputerowej wysokiej jakości (tzw. tytuły 
„AAA”) oznacza lata pracy oraz kosztuje nierzadko miliony dolarów. 

Z punktu widzenia programisty, programowanie gier to specyficzna dziedzina, 
która łączy w jednym wspólnym celu m.in. inżynierię oprogramowania, sztuczną inte¬ 
ligencję, symulacje fizyczne, przetwarzanie sygnałów oraz właśnie renderowanie akce- 
lerowanej sprzętowo, trójwymiarowej grafiki czasu rzeczywistego. Tematem niniejszej 
pracy jest wyłącznie ta ostatnia. Programowanie gier odróżnia od programowania in¬ 
nego rodzaju aplikacji wiele cech. Przykładowo, ze względu na wydajność działania 
kodu, językiem programowania obowiązującym w tej dziedzinie jest C++ O, podczas 
gdy aplikacje biznesowe najczęściej pisze się w językach łatwiejszych do opanowania 
i użycia, takich jak Java albo C#. 

Wraz z rozwojem gier komputerowych i wzrostem ich złożoności powstał odrębny 
element składowy tego typu aplikacji zwany silnikiem. Silniki bywają tworzone i li¬ 
cencjonowane jako osobne produkty i coraz więcej firm decyduje się na tworzenie gier 
w oparciu o zewnętrzny silnik zamiast tworzyć własny. Silnik nie jest pojęciem ściśle 
zdefiniowanym. Intuicyjnie można powiedzieć, że silnik (w informatyce) to rozbudo¬ 
wana biblioteka programowa realizująca zasadniczą funkcjonalność aplikacji danego 
rodzaju. Mianem silnika przyjęło się przy tym określać pewne rodzaje bibliotek ta¬ 
kie jak: silnik renderujący w przeglądarce internetowej WWW czy silnik bazy danych, 
a w przypadku gier komputerowych — silnik graficzny, silnik fizyczny oraz silnik gry. 

Silnik graficzny albo renderer to biblioteka realizująca renderowanie grafiki czasu 
rzeczywistego. W celu realizacji tego zadania wykorzystuje ona bibliotekę graficzną po¬ 
zwalającą na użycie akceleracji sprzętowej oferowanej przez kartę graficzną. Obecnie 
na platformie PC bibliotekami takimi są DirectX [3l oraz OpenGL (4). Silnik graficzny 
jest potrzebny w bardziej złożonych grach, ponieważ stanowi dodatkową warstwę abs¬ 
trakcji. Korzystając bezpośrednio z biblioteki graficznej, programista musi zajmować 
się renderowaniem trójkątów, manipulowaniem teksturami, buforami, shaderami i in¬ 
nymi zasobami niskiego poziomu. Silnik daje tymczasem dostęp do obiektów bardziej 
abstrakcyjnych, jak scena, encja, światło czy materiał, ukrywając przed użytkowni¬ 
kiem szczegóły implementacyjne. 
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1.1. Przegląd literatury 

Dostępne jest dużo literatury poświęconej grafice komputerowej czasu rzeczywistego, 
ale źródła bywają na różnym poziomie zaawansowania — od tzw. internetowych tuto- 
riali adresowanych do początkujących, poprzez książki kompleksowo wprowadzające 
do tematyki programowania gier, książki bardziej wyspecjalizowane i adresowane do 
bardziej zaawansowanych programistów, aż po artykuły i prezentacje naukowe, czę¬ 
sto pochodzące z konferencji takich jak SIGGRAPH czy Gamę Developers Conference. 
Literatury w języku angielskim jest dostępnej wielokrotnie więcej, niż w języku pol¬ 
skim. 

Pozycje wprowadzające w tematykę programowania grafiki czy też uczące korzysta¬ 
nia z biblioteki graficznej takie jak DirectX z przyczyn oczywistych nie są tutaj opisane. 
Bardzo ważnym źródłem w tym kontekście jest oficjalna dokumentacja dostarczona 
przez producenta danej biblioteki (np. DirectX SDK). Na wzmiankę zasługuje nato¬ 
miast literatura wprowadzająca podstawy teoretyczne grafiki komputerowej, jak ID . 

Istotnym zagadnieniem jest wiedza matematyczna potrzebna do implementacji 
silnika. Jej zakres obejmuje przede wszystkim geometrię analityczną z pojęciami spe¬ 
cyficznymi dla tej dziedziny, jak macierze transformacji i kwaterniony w zastosowaniu 
do reprezentowania rotacji i orientacji. Istnieje kilka pozycji książkowych wykładają¬ 
cych podstawy matematyczne potrzebne w programowaniu grafiki i gier. Spośród nich 
autor poleca (5). 

Książek poświęconych typowo architekturze silnika graficznego czy silnika gry jest 
stosunkowo niewiele mm. Wiele zagadnień potrzebnych podczas implementacji sil¬ 
nika zostało zawarte w (8j. 

Podział przestrzeni Kluczowym elementem optymalizacji podczas renderowania gra¬ 
fiki czasu rzeczywistego jest jak najszybsze (jak najprostsze i jak najwcześniejsze) od¬ 
rzucanie możliwie dużych elementów z dalszego renderowania w danej klatce. Owo od¬ 
rzucanie, nazywane też przycinaniem (ang. culling) odbywa się na wszelkich etapach 
procesu renderowania. Na poziomie procesora karty graficznej (GPU) jest to odrzu¬ 
canie pojedynczych pikseli ( Z-Test , Alpha-Test, Stencil-Test) oraz trójkątów ( Backface 
Culling ). Na poziomie procesora głównego (CPU) może to być odrzucanie całych obiek¬ 
tów, co do których można łatwo stwierdzić, że są poza zasięgiem pola widzenia (ang. 
Frustum Culling). 

Na jeszcze wyższym poziomie można odrzucać całe fragmenty wirtualnego świata 
(sceny). Potrzebny jest do tego pewien podział sceny na części i jej reprezentacja za 
pomocą specjalnej struktury danych. Wynaleziono wiele takich struktur, a używające 
ich techniki nazywane są technikami podziału przestrzeni. 

Trzeba przy tym podkreślić, że sceny trójwymiarowe dzieli się ogólnie na prze¬ 
strzenie zamknięte (ang. Indoor ) i przestrzenie otwarte (ang. Outdoor). Przestrzenie 
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zamknięte składają się z układu pomieszczeń połączonych korytarzami. Przestrze¬ 
nie otwarte natomiast pokazują rozległy teren z ustawionymi na nim obiektami (jak 
drzewa, budynki) oraz sklepieniem niebieskim. Inne techniki podziału przestrzeni 
są skuteczne w zastosowaniu do przestrzeni zamkniętych, a inne w zastosowaniu do 
przestrzeni otwartych. Osobnym zagadnieniem jest skuteczne połączenie tych dwóch 
rodzajów scen tak, aby wirtualna kamera mogą między nimi przechodzić w sposób 
płynny (ang. Seamless ). 

Niektóre najpopularniejsze techniki podziału przestrzeni to: 

• BSP (ang. Binary Space Partitioning) polega na podziale przestrzeni dowolnie 
zorientowanymi płaszczyznami, co w efekcie pozwala uzyskać drzewo binarne. 
Historię wynalezienia tej techniki podaje (9). 

• Drzewo K-D (ang. kd-tree) polega na podziale przestrzeni płaszczyznami zawsze 
prostopadłymi do osi układu współrzędnych. 

• Drzewo czwórkowe (ang. Quadtree ) polega na rekurencyjnym podziale prosto¬ 
kątnego obszaru na cztery prostokątne podobszary. Ta struktura danych została 
opisana w fioł . Zobacz rys. O 

• Drzewo ósemkowe (ang. Octree) polega na rekurencyjnym podziale prostopa¬ 
dłościanu na osiem prostopadłościanów podrzędnych. Tworzy drzewo, w którym 
każdy węzeł jest albo liściem, albo posiada 8 podwęzłów. 

• Portale to technika polegająca na podziale mapy na sektory połączone tzw. por¬ 
talami. Obszar widoczny w zasięgu kamery jest przycinany przez portale, co 
pozwala stwierdzić, które sektory są widoczne z danego punktu widzenia. 



Rys. 1.1. Drzewo czwórkowe dzielące rekurencyjnie płaszczyznę pozwala szybko wyszukiwać 
rozmieszczone na niej punkty. (Źródło: Wikipedia) 
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1. Wprowadzenie 


Techniki podziału przestrzeni to bardziej ogólne pomysły niż konkretne algorytmy. 
Można je modyfikować, a nawet łączyć. Istnieje wiele często używanych modyfikacji, 
na przykład swobodne drzewo ósemkowe (ang. Loose Octree) opisane w (TT). 

Oświetlenie i materiały Zagadnieniem kluczowym w renderowaniu realistycznej 
grafiki są obliczenia oświetlenia. Na wysokim poziomie abstrakcji łączą się w tym 
miejscu parametry opisujące materiał, z którego wykonana jest dana powierzchnia 
oraz światło, które na nią pada. Na niskim poziomie celem jest wyliczenie ostatecz¬ 
nego koloru piksela. Oświetlenie polega przy tym tak naprawdę na przyciemnianiu 
(ang. shading) oryginalnego koloru materiału. 

Metody oświetlenia w grafice czasu rzeczywistego podzielić można na statyczne 
i dynamiczne. Oświetlenie statyczne to takie, dla którego jasność poszczególnych 
miejsc na scenie (np. na podłodze, suficie, na ścianach) została wcześniej obliczona 
i jest tylko prezentowana. To pozwala na obliczenie jej dokładnymi, dającymi reali¬ 
styczne efekty metodami z grupy oświetlenia globalnego (ang. Global Mumination ), 
które są zbyt wolne do zastosowania w czasie rzeczywistym (np. metoda energetyczna 
— ang. Radiosity albo metoda map fotonowych — ang. Photon Mapping). Wadą 
tego podejścia jest niemożność zmiany warunków oświetleniowych w czasie pracy 
programu. Wyliczony kolor i jasność oświetlenia w poszczególnych miejscach skła¬ 
dowana jest zwykle na tzw. mapach światła (ang. Lightmap ), choć istnieją też bardziej 
zaawansowane rozwiązania, np. Radiosity Normal Mapping 1121 . 

Oświetlenie dynamiczne polega na wyliczaniu wpływu światła na każdy punkt 
powierzchni w czasie rzeczywistym. To podejście dzieli się dalej na oświetlenie per 
vertex, polegające na dokonywaniu obliczeń tylko dla wierzchołków siatki i interpolo¬ 
waniu wyników na powierzchni trójkątów (co odpowiada obecnie obliczeniom w Ver- 
tex Shaderze) oraz per pixel, polegające na obliczaniu pełnego oświetlenia dla każ¬ 
dego piksela rysowanego obrazu (co odpowiada obecnie obliczeniom w Pixel Shade¬ 
rze). Oświetlenie per vertex jest —jak łatwo można się domyślić — bardziej wydajne, 
ale zarazem wyglądające dużo mniej realistycznie. Popularne obecnie na rynku karty 
graficzne posiadają już wydajność i możliwości pozwalające na realizowanie dynamicz¬ 
nego oświetlenia per pixel. 

Podstawą obliczeń oświetlenia jest cieniowanie Gourauda 1131 . Zobacz rys. |1.2[ 
Do tych obliczeń potrzebne są przede wszystkim wektor wskazujący kierunek od da¬ 
nego punktu do źródła światła oraz wektor normalny, prostopadły do powierzchni 
w tym punkcie. Ponieważ w grafice 3D czasu rzeczywistego powierzchnie reprezento¬ 
wane są za pomocą siatki trójkątów, wektory normalne zapisywane są w wierzchoł¬ 
kach i interpolowane na powierzchni trójkątów, co pozwala uzyskać w miarę gładkie 
cieniowanie nawet dla słabo steselowanych powierzchni. 

Głównym rodzajem oświetlenia jest oświetlenie rozproszone (ang. Diffuse) wyli¬ 
czane zgodnie z prawem Lamberta. Prawo to mówi, że intensywność światła padają- 
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Rys. 1.2. Obiekt z widocznym oświetleniem typu rozproszonego (ang. Diffuse) i odblaskiem 

(ang. Specular). (Źródło: Wikipedia) 

cego na powierzchnię jest wprost proporcjonalna do cosinusa kąta między kierunkiem 
wskazującym na źródło światła, a kierunkiem prostopadłym do powierzchni. Ten z ko¬ 
lei jest równy iloczynowi skalarnemu wspomnianych wyżej dwóch wektorów (o ile są 
one znormalizowane), co pozwala szybko obliczać takie równanie. 

Drugim ważnym składnikiem oświetlenia, obecnym na powierzchniach błyszczą¬ 
cych, jest odblask (ang. Specular). Do jego obliczenia potrzebna jest znajomość 
trzeciego wektora wskazującego kierunek od danego punktu do pozycji obserwatora 
(kamery). Istnieją dwa najważniejsze modele odblasku. Model Phonga 1141 jest do¬ 
kładniejszy, natomiast model Blinna 1151 jest prostszy do obliczania. 

Wynalezione zostało wiele modeli efektów, których zastosowanie może dodatkowo 
wzbogacić efektowność i realizm renderowanych scen. Alfa-blending 1161 (ang. Alpha- 
Blending) pozwala na uzyskiwanie obiektów półprzezroczystych. Mapowanie środo¬ 
wiskowe (ang. Environmental Mapping ) 1171 pozwala uzyskać odbicie obrazu sceny 
otaczającej obiekt na tym obiekcie. Half-Lambert (j'8'l to dodatkowa modyfikacja 
wzoru Lamberta przydatna w niektórych sytuacjach. Oświetlenie anizotropowe (ang. 
Anisotropic Lighting) |T9, [20]| to rzadko stosowany efekt pozwalający na oświetle¬ 
nie powierzchni posiadającej mikrostrukturę, takiej jak włosy, tkanina, polerowany 
metal. 


Mapowanie tekstur i wypukłości Trójkąty, z których złożona jest cała renderowana 
grafika, nie są pokrywane jednolitym kolorem. Nawet w dobie kart graficznych zdol¬ 
nych narysować w czasie rzeczywistym wiele milionów trójkątów na sekundę, drobne 
szczegóły powierzchni nie są reprezentowane przez gęstą siatkę trójkątów, ale przez 
nierzadko całkiem duże trójkąty pokryte rozciągniętym na ich powierzchni dwuwy¬ 
miarowym, bitmapowym obrazem, który w tym kontekście nazywany jest teksturą. 

Mapowanie tekstur (ang. Texture Mapping ) wynalazł Edwin Catmull 1211 . Od tego 
czasu powstało — i nadal powstaje — wiele technik bardziej zaawansowanego mapo¬ 
wania tekstur, które nie tylko odwzorowują kolorystykę, ale także fakturę nierówności 
materiału, z którego wykonany ma być wirtualny obiekt. 
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Najprostszą techniką mapowania nierówności (ang. Bump Mapping) jest mapowa¬ 
nie normalnych (ang. Normal Mapping) (221 . Polega ona na używaniu do obliczeń 
oświetlenia per pixel wektorów normalnych pobranych ze specjalnej tekstury zwanej 
mapą normalnych (ang. Normal Map), w której w składowych kolorów RGB (czer¬ 
wony, zielony, niebieski) upakowane są tak naprawdę składowe (x, y. z) tych wekto¬ 
rów. Zastosowanie mapy normalnych wyrażonej w przestrzeni stycznej (ang. Tangen 
Space) wymaga przekształcania do tej przestrzeni pozostałych wektorów biorących 
udział w obliczaniu oświetlenia (jak wektor kierunku do światła czy kierunku do ob¬ 
serwatora). Wektory tworzące bazę tego układu współrzędnych to, oprócz wektora 
normalnego (ang. Normal ), dwa wektory styczne do powierzchni w danym punkcie, 
nazywane po ang. Tangent i Binormal. 

Dalsze polepszenie wizualnej jakości renderowanej powierzchni można uzyskać 
stosując mapowanie uwzględniające różnice w przesunięciu punktów znajdujących się 
wyżej względem tych bardziej zagłębionych w wirtualnej fakturze powierzchni, czyli 
efekt paralaksy. Służy do tego Parallax Mapping 1231 . Oryginalny efekt posiada 
jednak wady, dlatego powstało wiele jego odmian, jak Relief Mapping |24l , Parallax 
Occlusion Mapping [25], Cone Step Mapping 1261 . czy opublikowany w ubiegłym roku 
Relaxed Cone Stepping 1271 . Zobacz rys. |1.3[ 



Rys. 1.3. Relcuced Cone Stepping (po prawej) wykonany na sześcianie z użyciem specjalnie 
przygotowanej tekstury (po lewej). (Źródło: 127) ] 


Renderowanie cieni W naturze cień powstaje tam, gdzie nie dochodzi światło. W gra¬ 
fice komputerowej cień może powstawać w ten sam sposób podczas obliczania oświe¬ 
tlenia metodami z grupy Global Illumination. Nie są to jednak metody nadające się do 
zastosowania w czasie rzeczywistym przy mocy obliczeniowej, jaką dysponuje współ¬ 
czesny sprzęt graficzny. Z kolei w technikach oświetlenia stosowanych obecnie w gra¬ 
fice czasu rzeczywistego cień nie powstaje automatycznie. Dlatego renderowanie cieni 
jest osobnym zagadnieniem. 

Istnieją dwie główne techniki stosowane do renderowania możliwie dokładnego, 
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rzucanego przez obiekty cienia w czasie rzeczywistym. Bryła cienia (ang. Shadow Vo- 
lume) 1281 wykorzystuje posiadany przez karty graficzne bufor szablonu (ang. Stencil 
Buffer) i rysuje do niego geometrię obiektu rzucającego cień, rozciągniętą w kierunku 
padania światła. Przecięcia tej geometrii bryły cienia z normalną geometrią sceny po¬ 
zwalają na wyliczenie miejsc, w których dany obiekt zasłania źródło światła. Zaletą 
tej metody jest dokładne odwzorowanie kształtu obiektu. Wadą natomiast — duże 
zapotrzebowanie na wydajność karty graficznej w kwestii renderowania pikseli (ang. 
Fillrate), trudność w uzyskaniu miękkich krawędzi cienia oraz konieczność specjal¬ 
nego przygotowania geometrii obiektu do jej rozciągania w kierunku padania światła. 

Drugą stosowaną powszechnie techniką jest mapowanie cienia (ang. Shadow 
Mapping — SM) 1291 . W tworzonych i wydawanych obecnie grach i silnikach gra¬ 
ficznych zdaje się ona uzyskiwać pozycję dominującą. Opiera się na dodatkowym 
przebiegu renderującym całą scenę z punktu widzenia źródła światła do specjalnej 
tekstury zwanej mapą cienia (ang. Shadow Map), w której zamiast koloru zapisana 
jest głębokość (czyli jakby odległość najbliższego punktu od światła w danym kie¬ 
runku). Następnie ta tekstura jest wykorzystywana przy normalnym renderowaniu 
sceny oświetlonej danym światłem w celu stwierdzenia, czy dane miejsce rysowanej 
powierzchni nie jest zasłonięte przez jakiś punkt leżący bliżej źródła światła w linii 
prostej. 

Technika mapy cienia wymaga odpowiednich operacji matematycznych (przekształ¬ 
ceń układu współrzędnych) oraz wykonywania testu porównującego odległość danego 
punktu z odległością zapisaną w mapie cienia. Powstaje przy tym wiele problemów, 
które liczni badacze próbowali rozwiązać na różne sposoby. Podstawowym kryterium 
użyteczności danej metody jest możliwość jej realizacji z użyciem akceleracji sprzęto¬ 
wej na współczesnych kartach graficznych. 

Jednym z problemów są „ząbkowane” krawędzie cienia wynikające ze skończonej 
rozdzielczości mapy cienia. W celu wygładzenia tych krawędzi zaproponowane zostało 
filtrowanie tekstury, z których najprostszym jest Percentage Closer Filtering (PCF) 
|30l . Daje ono przy okazji złudzenie miękkiego cienia, które jednak dalekie jest od 
w pełni realistycznego. Dlatego powstało wiele sposobów na jego rozwinięcie. Karty 
graficzne z układem firmy nVidia potrafią wykonywać PCF sprzętowo 13ll . 

Innym problemem jest rzucanie cienia przez światło typu punktowego (ang. Point 
Light), które świeci z jednego punktu we wszystkich kierunkach (jak np. żarówka). 
Mapa cienia dla takiego światła musi je otaczać ze wszystkich stron. Najprostszym 
rozwiązaniem jest użycie w tym celu tekstury sześciennej (ang. Cube Textwre), jednak 
to wymaga osobnego renderowania całej sceny do każdej z 6 ścian tej tekstury. Za¬ 
proponowano optymalizację polegającą na użyciu tylko dwóch tekstur i mapowania 
dwuparaboloidalnego (ang. Dual Paraboloid Mapping ) |32| . Jednak z eksperymen¬ 
tów autora niniejszej pracy wynika, że dla bardziej złożonych scen, w przeciwieństwie 
do prostych scen testowych, technika ta jest niemożliwa do zastosowania z powodu 
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nieliniowego charakteru transformacji paraboloidalnej. 

Jednym z największych problemów podczas renderowania cieni tą metodą w sce¬ 
nach typu Outdoor jest jednakowa rozdzielczość mapy cienia względem współrzęd¬ 
nych globalnych świata. Oznacza to, że chcąc rzucać na cały widoczny obszar sceny 
cień od światła typu kierunkowego (ang. Directional Light), np. od Słońca, „ząbek” 
odpowiadający pojedynczemu tekselowi mapy cienia ma na ekranie bardzo mały roz¬ 
miar dla miejsc odległych od kamery (na końcu pola widzenia), a bardzo duży dla 
miejsc w pobliżu kamery. Dlatego powstały metody reparametryzacji, które dodają do 
przekształcenia stosowanego przy mapowaniu cienia dodatkową, nieliniową transfor¬ 
mację (np. perspektywiczną), dzięki której więcej miejsca na mapie cienia poświęcone 
zostaje obszarowi bliskiemu w stosunku do obserwatora, a mniej obszarom odległym. 
Podstawowym rozwiązaniem tego rodzaju jest Perspective Shadow Maps (PSM) l33l . 
Zobacz rys. 1.4[ Ze względu na trudność w implementacji i pewne problemy powstały 
modyfikacje tej metody — Light Space Perspectwe Shadow Maps (LiSPSM) |34| . Tra- 
pezoidal Shadow Maps (TSM) 1351 oraz Extended Perspectwe Shadow Maps (XPSM) 
(36). 



Rys. 1.4. Perspectwe Shadow Mapping: Po lewej pokazana mapa cienia, po prawej scena 

wyrenderowana z jej użyciem. (Źródło: I33l l 



Renderowanie terenu Renderowanie przestrzeni otwartych znajduje zastosowania 
w wielu aplikacjach wizualizacyjnych oraz w pewnych gatunkach gier (np. gry strate¬ 
giczne, gry CRPG). Doskonałym punktem startowym do zdobywania wiedzy na temat 
przestrzeni otwartych w grafice komputerowej (we wszelkich aspektach — od terenu 
poprzez jaskinie, niebo, wodę, aż po drzewa, trawę i budynki) stanowi strona interne¬ 
towa vterrain.org CEZ). 

Podstawowym składnikiem sceny typu otwartego jest teren, czyli pofalowana po¬ 
wierzchnia odzwierciedlająca wzniesienia usypane z ziemi. Teren renderowany jest 
zwykle jako mapa wysokości (ang. Heightmap, patrz rys. |1.5) , tj. taka siatka trój¬ 
kątów, w której wierzchołki są rozmieszczone równomiernie w płaszczyźnie poziomej 
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Rys. 1.5. Teren z widoczną siatką, z której jest zbudowany. (Źródło: 1371 1 

i przesunięte w osi pionowej stosownie do wzorca ukształtowania terenu, pobieranego 
najczęściej z jasności pikseli specjalnej tekstury nazywanej właśnie mapą wysokości. 

Wynalezione zostało wiele algorytmów wydajnego renderowania terenu. Niektóre 
z nich opisane są w książce traktującej wyłącznie na ten temat (38). Jedną z najprost¬ 
szych takich technik jest Geomipmapping 1391 . Bardzo dobrym, ponieważ skutecz¬ 
nym a zarazem banalnie prostym rozwiązaniem problemu pęknięć (ang. Crackś) po¬ 
wstających w tej technice jest zastosowanie „spódniczki” (ang. Skirt) opisanej w (40). 
Inny algorytm renderowania terenu to ROAM — ang. Realtime Optimally-Adapting 
Meshes (411 . Jeszcze innym, stosunkowo zaawansowanym rozwiązaniem w tym za¬ 
kresie jest Clipmapping 1421 . 

Niektóre z tych technik nienajlepiej współpracują ze współczesnym sprzętem gra¬ 
ficznym, ponieważ operują na pojedynczych trójkątach. Wynalezione wiele lat temu, 
kiedy karty graficzne miały dużo mniejszą wydajność, teraz wykonują na CPU nad¬ 
miernie dużo obliczeń. Współczesne karty graficzne są zdolne do renderowania ogrom¬ 
nej liczby trójkątów na sekundę, jednakże do uzyskania jak najwyższej wydajności 
ważne jest podawanie tej geometrii dużymi porcjami (ang. Batcłi). W przeciwnym 
wypadku spada wydajność renderowania. 

Do realistycznego wyrenderowania terenu potrzebne jest, oprócz ukształtowania 
siatki, także odpowiednie pokrycie teksturą. To również jest wyzwaniem, jako że roz¬ 
legły teren nie powinien posiadać jednej tekstury, ale wiele tekstur płynnie między 
sobą przechodzących (np. śnieg, trawa, piasek, ziemia). Najpopularniejszym rozwią¬ 
zaniem tego problemu jest Texture Splatting 1431 . 

Renderowanie rozległego terenu rodzi dodatkowy problem wydajnego ogranicza¬ 
nia zakresu renderowanej geometrii do tej pozostającej w polu widzenia. Stosowane 
bywają do tego techniki podziału przestrzeni takie jak drzewo czwórkowe (ang. Quad- 
tree). 
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Innym problemem, jaki szczególnie daje o sobie znać podczas renderowania prze¬ 
strzeni otwartych jest konieczność dynamicznej zmiany poziomu szczegółowości ren- 
derowanej geometrii wraz z odległością (LOD — ang. Level of Detail). O ile w prze¬ 
strzeniach zamkniętych liczba widocznych obiektów jest zwykle znacznie ograniczona 
(niekiedy do zaledwie kilku) przez ściany wąskich korytarzy i ciasnych pomieszczeń, 
o tyle w otwartym terenie widoczne mogą być jednocześnie nawet setki albo tysiące 
obiektów takich jak drzewa czy jakieś postacie. Rozwiązaniem dla wydajnego ren¬ 
derowania takiej sceny jest właśnie LOD — wyświetlenie z mniejszą szczegółowością 
tych obiektów i tych części terenu, które znajdują się daleko od kamery. LOD można 
stosować do różnych aspektów renderowania grafiki, np. złożoności siatki trójkątów, 
dokładności obliczeń oświetlenia, płynności animacji, a nawet szczegółowości obliczeń 
fizyki czy sztucznej inteligencji. 

Przełączanie się poziomów szczegółowości fragmentów terenu w miarę ich przybli¬ 
żania lub oddalania od kamery powoduje nieprzyjemny efekt „przeskakiwania” (ang. 
Popping) . Można go zniwelować poprzez zastosowanie CLOD — ang. Continuous Level 
OfDetails. 

Renderowanie drzew i trawy Wraz z postępem w grafice komputerowej, coraz czę¬ 
ściej prezentowane są nie tylko budynki, maszyny i inne sztuczne twory, ale również 
dużo trudniejsze do realistycznego wyrenderowania obiekty naturalne takie jak ro¬ 
śliny. Sposób renderowania drzew przeszedł długą ewolucję. Pierwsze drzewa poka¬ 
zywane były zwykle jako „plakaty” (ang. Billboard ), czyli płaskie bitmapy zwrócone 
zawsze przodem do kamery. Innym częstym rozwiązaniem było złożenie trójwymiaro¬ 
wego obrazu drzewa z kilku przecinających się, oteksturowanych prostokątów. Wraz 
ze wzrostem mocy obliczeniowej kart graficznych pojawiła się możliwość bardziej do¬ 
kładnego modelowania drzew wraz ze szczegółami takimi, jak kształt pnia, gałęzi i po¬ 
szczególne grupy liści (choć nie były to — i wciąż nie są — pojedyncze liście). 

Ręczne tworzenie modelu takiego drzewa przez artystę wymaga jednak dużo pracy. 
Inną wadą tego podejścia jest pracochłonność otrzymania wielu podobnych, ale nie¬ 
jednakowych modeli. Dlatego wirtualne drzewa są jednym z tych obszarów grafiki, 
w których proceduralne generowanie sprawdza się równie dobrze, a nawet lepiej niż 
jego kreowanie przez artystę. Powstało wiele rozwiązań skupiających się czy to na 
algorytmach generowania kształtu drzew (pnia, gałęzi, liści), czy też na ich wydajnym 
renderowaniu w czasie rzeczywistym. Spośród tych pierwszych na uwagę zasługuje 
przede wszystkim l44l . Podczas opracowania metody renderowania drzew nieoce¬ 
nioną inspiracją może być studiowanie wyglądu i działania technologii SpeedTree 1451 
(szczególnie dostępnego do pobrania za darmo dema Trees of Pangaea), która skupia 
się ściśle na generowaniu i renderowaniu realistycznych, proceduralnych drzew oraz 
jest licencjonowana na potrzeby wielu współczesnych gier i innych aplikacji. Zobacz 
rys. [L6} 


15 





1. Wprowadzenie 



Rys. 1.6. Przykład generowania i renderowania fotorealistycznej roślinności w czasie 

rzeczywistym. (Źródło: 1451 1 

Osobnym, niebanalnym zagadnieniem jest wydajne renderowanie trawy. Źdźbła 
trawy występują w ogromnej ilości pokrywając siatkę terenu, co wymaga specjalnego 
potraktowania tematu optymalizacji ich renderowania. Pewnie rozwiązania prezentują 
artykuły 14611471 . Inne, bardzo zaawansowane podejście oparte na trzypoziomowym 
LOD opracowane zostało przez badaczy z INRIA 1481 . 

Inne efekty przestrzeni otwartych Podczas renderowania przestrzeni otwartych 
zachodzi konieczność prezentowania w jakiś sposób także sklepienia niebieskiego, na 
które składają się elementy takie jak: chmury. Słońce, gwiazdy i inne ciała niebieskie. 
Najprostsza metoda to tzw. Skybox — ogromny sześcian poruszający się wraz z ka¬ 
merą (ale nie obracający się wraz z nią), oteksturowany od środka za pomocą tekstury 
sześciennej przedstawiającej niebo wraz z chmurami. Słońce, teren na horyzoncie itd. 
Realistyczne renderowanie dynamicznie zmieniającego się nieba nieba jest tematem 
wielu publikacji. Większość z nich skupia się na konkretnym zagadnieniu, takim jak 
realistyczny dobór kolorów tła czy model ruchu ciał niebieskich. 

Wdzięcznym tematem badań są techniki renderowania chmur. Najprostsza me¬ 
toda polega na prezentowaniu przesuwających się, płaskich fotografii przedstawia¬ 
jących chmury. Do proceduralnego generowania realistycznych formacji tego typu 
doskonale nadaje się szum Perlina 1491 . Możliwe są także inne, bardziej zaawanso¬ 
wane podejścia. Na przykład w zastosowaniach, w których konieczne jest wlatywanie 
wirtualną kamerą do wnętrza chmur, a nie tylko oglądanie ich z powierzchni Ziemii 
(jak w symulatorze lotu Microsoft Flight Simulator) zastosowanie mogą znaleźć me¬ 
tody takie jak opisana w 1501 . Zobacz rys. 

Realizmu przestrzeniom otwartym dodają efekty atmosferyczne — opady deszczu, 
śniegu czy burza piaskowa (zależnie od rodzaju wirtualnej krainy). W tej materii, po- 
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Rys. 1.7. Rendering fotorealistycznych chmur w czasie rzeczywistym. (Źródło: 1501 1 

dobnie jak w całej grafice komputerowej, każdy doświadczony programista jest w sta¬ 
nie wymyślić własne oryginalne rozwiązania. Niezwykle zaawansowane i kompleksowe 
podejście do wszelkich efektów związanych z opadami deszczu prezentuje l5ll . 

Podobnie jest z powierzchnią wody. Woda jest trudna do realistycznego przedsta¬ 
wienia, ponieważ wymaga zamodelowania wielu zjawisk optycznych takich jak reflek¬ 
sja i refrakcja światła, kaustyki (ang. Caustics) itd. Wymaga ponadto pokazywania 
zarówno tego, co znajduje się pod powierzchnią jak i obrazu odbitego od powierzchni. 
Dlatego jakość renderowanej wody często bywa poświęcana na rzecz prostoty obli¬ 
czeń (a co za tym idzie — wydajności). Nic więc dziwnego, że w praktycznie każdej 
grze spotkać można inaczej wyglądającą, inaczej zrealizowaną wodę. Bardzo dobra, 
zaawansowana implementacja renderowania wody znajduje się w [521 . 


Efekty postprocessingu Postprocessing (co można przetłumaczyć jako „po-przetwa- 
rzanie”) to grupa efektów nakładanych na gotowy już obraz w sposób dwuwymiarowy. 
Istnieje bardzo wiele takich efektów. Autor wybrał i zaimplementował w swoim kodzie 
niektóre z nich. 

HDR (ang. High Dynamie Rangę) to pojęcie wprowadzone przez |E>3]. Oznacza sze¬ 
roki zakres jasności, jaka występuje w naturze i jaka jest obserwowalna przez ludzkie 
oko. Zarówno współczesne kamery i aparaty fotograficzne, jak i monitory czy dru¬ 
karki nie są w stanie oddać tak szerokiego zakresu jasności. Dlatego realizm wirtu¬ 
alnych scen można ulepszyć uwzględniając zjawisko HDR w procesie renderowania. 
Wykonanie pełnego renderingu HDR wymaga specjalnego podejścia do całego pro¬ 
cesu, m.in. wykorzystania tekstur w formacie zmiennoprzecinkowym lub RGBE (Red, 
Green, Blue, Exponent) celem odwzorowania szerszego zakresu jasności, niż oferuje to 
standardowy format piksela typu A8R8G8B8 (który przeznacza tylko 8 bitów na skła- 
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dową). Można jednakże spróbować zastosować efekty nakładane na koniec procesu 
renderowania HDR bez wykorzystywania prawdziwego HDR. Powstaje wówczas tzw. 
Fake HDR, który wciąż polepsza jakość i realizm renderowanej sceny, mimo swojej 
prostoty. Te efekty to Tonę Mapping 1541 i Bloom 1551 . Zobacz rys. |1.8 



Rys. 1.8. Tonę Mapping z różnymi wartościami ekspozycji. (Źródło: l55l l 

Sprzężenie zwrotne (ang. Feedback ) [3] to nakładanie poprzedniej klatki obrazu 
na nową w sposób półprzezroczysty. Zastosowanie znajduje np. w wizualizacjach 
muzycznych, takich jak wtyczka AVS w odtwarzaczu Winamp. W grafice 3D może 
posłużyć do otrzymania różnorodnych efektów, jak np. proste rozmycie ruchu (ang. 
Motion Biur) dla całego obrazu. 

Błyski soczewek (ang. Lens Flarę ) to prosty efekt powstający w wyniku zjawisk 
optycznych, jakie zachodzą na soczewkach obiektywu kamery, kiedy wpada do niej 
światło prosto od Słońca lub innego silnego źródła. W naturze efekt ten jest nie¬ 
pożądany, ale w grafice komputerowej może dodać scenie realizmu podkreślając ja¬ 
skrawość źródła światła, niemożliwą do oddania na ekranie monitora bezpośrednio. 
Sposób implementacji tego efektu opisuje np. O. 

Mgła ciepła (ang. Heat Haze) to z kolei zjawisko falowania obrazu załamującego 
się w powietrzu ogrzewanym np. przez rozgrzany asfalt jezdni albo płomień. Sposób 
implementacji tego efektu opisuje 1561 . 


Efekty specjalne Pewne zjawiska są wolumetryczne, czyli posiadające charakter 
przestrzenny. Najpopularniejszym efektem tego rodzaju jest efekt cząsteczkowy 
(ang. Particie Ęffect). Zobacz rys. |1.9 Jego realizacja polega na renderowaniu zbioru 
punktów (cząsteczek), z których każdy staje się w procesie renderowania kwadratem 
zwróconym zawsze prostopadle do kierunku patrzenia kamery, pokrytym półprzezro¬ 
czystą teksturą. Dzięki wykorzystaniu odpowiedniej tekstury, odpowiednich ustawień 
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blendingu (często używany bywa tutaj blending addytywny) oraz odpowiednio dużej 
liczby cząsteczek, małym nakładem pracy uzyskać można niezwykle efektowne anima¬ 
cje przedstawiające np. ogień, dym, iskry czy jakieś fantastyczne, magiczne drobinki 
„energii”. 



Rys. 1.9. Efekt cząsteczkowy zastosowany do renderowania ognia. (Źródło: Wikipedia) 

Efekty cząsteczkowe podzielić można na stanowe i bezstanowe (571. Efekty czą¬ 
steczkowe bezstanowe polegają na wyliczaniu wszystkich parametrów cząstki (jak 
pozycja, rozmiar, kolor, orientacja) w funkcji czasu ze ściśle określonego wzoru. To 
pozwala na ich łatwą i wydajną implementację realizowaną w pełni na GPU. Na¬ 
rzuca jednocześnie ograniczenie na ruch tych cząstek do pewnego stałego scenariu¬ 
sza. Efekty cząsteczkowe stanowe polegają na aktualizowaniu parametrów cząstek 
zgodnie z krokiem czasowym na podstawie ich stanu poprzedniego. Daje do dużo 
większą elastyczność w manipulowaniu tymi parametrami. Możliwe jest np. obli¬ 
czanie kolizji i odbić cząstek od geometrii mapy. Pojawiły się próby implementacji 
efektów cząsteczkowych stanowych przeliczanych na GPU, co stało się możliwe dzięki 
rosnącym możliwościom i elastyczności nowoczesnego sprzętu graficznego. 

Istnieje dużo innych efektów specjalnych, dla których wynalezione zostały uży¬ 
teczne modele i wydaje implementacje z użyciem akceleracji sprzętowej, a które nie 
zostały opisane w niniejszej pracy. Należą do nich np. mgła wolumetryczna (ang. 
Volumetric Fog) czy snopy światła (ang. Light Shafi). 

1.2. Charakterystyka dostępnych bibliotek graficznych 

Z układem scalonym karty graficznej bezpośrednio komunikuje się przeznaczony dla 
niej sterownik. Jednakże dla programisty udostępniony zostaje ujednolicony interfejs, 
niezależny od tego, kto jest producentem układu graficznego (np. NVIDIA, ATI/AMD, 
Intel) ani też jak nowoczesna jest to karta. Ów interfejs na platformie PC ma postać 
jednej z dwóch bibliotek: DirectX lub OpenGL. 
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Twórcą biblioteki DirectX jest firma Microsoft (3j. Jest ona przeznaczona na plat¬ 
formę PC z systemem Windows oraz konsolę XBox (której nazwa pochodzi właśnie od 
ang. DirectX-Box) . Wersje DirectX kompatybilne z Windows XP i Vista noszą obec¬ 
nie oznaczenie 9.0c i są dodatkowo oznaczane datą wydania konkretnej wersji (np. 
March 2008), a nowe aktualizacje ukazują się kilka razy w roku. Programowanie 
z użyciem DirectX wymaga zainstalowanego pakietu DirectX SDK w wybranej wersji. 
Od użytkownika natomiast wymagane jest, aby w swoim systemie posiadał zainstalo¬ 
waną bibliotekę DirectX (tzw. DirectX Redistributable) odpowiadającą tej wersji SDK, 
w której program został skompilowany (lub nowszą). 

Interfejs biblioteki DirectX jest obiektowy, oparty na technologii COM. Począwszy 
od wersji 8 nastąpiła jego znaczna reorganizacja i uproszczenie. Zniknął ścisły po¬ 
dział na część przeznaczoną do grafiki 2D i 3D (określane jako DirectDraw i Direct3D). 
DirectX jest kompletną biblioteką multimedialną, która oprócz części graficznej (Di- 
rect3D) wspiera też m.in. odtwarzanie dźwięku oraz obsługę urządzeń wejściowych 
(klawiatura, mysz i różnego rodzaju manipulatory, np. pady, kierownice). W skład 
DirectX wchodzi rozszerzenie D3DX, które stanowi bogatą bibliotekę funkcji matema¬ 
tycznych (zapewniającą operacje na wektorach, macierzach, kwaternionach, płasz¬ 
czyznach itp.), a także potrafiących wczytywać tekstury z plików w różnych formatach 
graficznych (m.in. BMP, JPEG, PNG, TGA, DDS), siatki modeli w formacie X i wielu 
innych. Językiem shaderów używanym w DirectX jest HLSL (ang. High Level Shading 
Language). 

Najnowszą wersją biblioteki jest DirectX 10. Jest ona niekompatybilna wstecz. 
Jej intefejs został całkowicie zreorganizowany, uproszczony, a wiele przestarzałych 
elementów zostało porzucone. Nowa wersja daje dostęp do nowych funkcji kart gra¬ 
ficznych najnowszej generacji (w chwili pisania tych słów), tj. GeForce 8000/9000 
(i ich odpowiedników firmy ATI/AMD), m.in. Shader Model 4. Niestety, DirectX 10 
do działania wymaga posiadania takiej karty, jak również systemu Windows Vista, 
gdyż nie ma wersji DirectX 10 dla Windows XP. To czyni najnowszą wersję biblioteki 
nienajlepszym wyborem. W chwili, kiedy takie karty graficzne są jeszcze stosunkowo 
drogie i niezbyt rozpowszecnione, a przejście na Windows Vista napotyka dużą niechęć 
użytkowników, pisanie aplikacji używających wyłącznie DirectX 10 byłoby znacznym 
ograniczeniem grona potencjalnych odbiorców. 

Drugą z bibliotek dających dostęp do możliwości karty graficznej jest OpenGL (ang. 
Open Graphics Library ) f4j. API to, stworzone przez Silicon Graphics Inc. (SGI), jest 
obecnie rozwijane przez grupę Khronos. Jest przenośne — pozwała na pisanie aplika¬ 
cji działających zarówno w Windows, jak i w Linux oraz na innych platformach. Nie 
wymaga od użytkownika instalacji żadnego oprogramowania — jest dostępny stan¬ 
dardowo w systemie Windows. 

OpenGL w powszechnej opinii uchodzi za bibliotekę prostszą do opanowania i przez 
to lepiej nadającą się do nauki programowania grafiki 3D dla początkujących. Owo 
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wrażenie jest jednak złudne, gdyż programista po pewnym czasie siłą rzeczy napo¬ 
tyka na przeszkody takie jak konieczność samodzielnego manipulowania wektorami 
i macierzam (która w Direct3D występuje od początku), a OpenGL w żaden sposób 
tego nie ułatwia (w przeciwieństwie do Direct3D, wyposażonego w dodatek D3DX). 
Interfejs OpenGL jest strukturalny, oparty na stanach. Z możliwości nowoczesnych 
kart graficznych korzysta się w nim przede wszystkim za pomocą tzw. rozszerzeń. W 
planach jest nowa wersja OpenGL 3.0, której API ma zostać zupełnie przeorganizo¬ 
wane i dostosowane do funkcjonalności najnowszych układów graficznych, podobnie 
jak Microsoft zrobił to w nowym DirectX 10. 

Biblioteki Direct3D i OpenGL mają niemal takie same możliwości oraz praktycznie 
taką samą wydajność. Dlatego nie sposób rozstrzygnąć jednoznacznie, która z nich 
jest lepsza. W obydwu można zaimplementować te same efekty graficzne. Obydwie 
te biblioteki są darmowe do wykorzystania zarówno dla programisty, jak i dla użyt¬ 
kownika. Jednakże faktem jest, że w chwili obecnej większość gier na PC powstaje 
przeznaczona dla systemu Windows i używa biblioteki DirectX. 

Biorąc pod uwagę powyższe kryteria, jak również osobiste preferencje autora, jako 
biblioteka graficzna wykorzystana podczas implementacji silnika, który jest przedmio¬ 
tem tej pracy, wybrany został DirectX 9.0c. 

1.3. Cel i zakres pracy 

Celem pracy jest stworzenie biblioteki programowej zwanej silnikiem grafiki trójwy¬ 
miarowej, z użyciem języka programowania C++ i biblioteki graficznej DirectX. W ten 
sposób autor chciał poznać, jak wygląda architektura i implementacja takiego silnika. 

Zakres pracy obejmuje: 

• badania literaturowe w dziedzinie renderowania grafiki trójwymiarowej, 

• badanie algorytmów i technik renderowania różnorodnych efektów graficznych, 

• badanie architektury silników graficznych 3D i rozważania nad problemami, 
które się przy tym pojawiają, 

• omówienie modułów i klas, z jakich składa się silnik graficzny i kod towarzy¬ 
szący, na którym się on opiera, 

• opracowanie przykładów zastosowania silnika (prototypów gier), 

• przeprowadzenie testów zaimplementowanego systemu, 

• analiza wydajności systemu na dostępnym współcześnie sprzęcie graficznym. 

Stworzony na potrzeby tej pracy kod nie może oczywiście dorównać możliwościami 
ani jakością silnikom rozwijanym przez wiele lat i przez wielu ludzi, czy to tworzonym 
w środowisku Open Source (jak Ogre3D, Irrlicht) czy też przez duże firmy z branży 
gier komputerowych (jak Unreal Engine firmy Epic Games czy id Tech 5 firmy id 
Software). Stanowi jednak względnie efektowny, kompletny oraz — co bardzo ważne 
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— ukończony projekt mogący teoretycznie znaleźć zastosowanie przy tworzeniu gry 
komputerowej lub symulacji w czasie rzeczywistym. 

Niniejsza praca ma charakter przeglądowy. W skład silnika graficznego wchodzi 
bardzo wiele różnych technik, algorytmów i innych rozwiązań, dlatego nie sposób opi¬ 
sać ich wszystkich dokładnie. Każda z nich mogłaby być tematem osobnej rozprawy. 
Ponadto celem niniejszej pracy nie jest wprowadzenie jakiegokolwiek zupełnie nowego 
rozwiązania, a raczej pokazanie, w jaki sposób można połączyć wybrane istniejące roz¬ 
wiązania aby zrealizować założony cel. Aczkolwiek przy implementacji tak rozbudo¬ 
wanego projektu programistycznego, siłą rzeczy zastosowane zostało wiele drobnych, 
nowatorskich pomysłów. 

W rozdziale |T] niniejszej pracy określona zostaje ściśle dziedzina, której praca doty¬ 
czy oraz wprowadzone zostaje pojęcie silnika graficznego. Przedstawiony jest również 
przegląd znanych technik realizacji poszczególnych efektów graficznych. W rozdziale 
[2] wprowadzony zostaje podział przedstawionego systemu na warstwy i opisane są po¬ 
szczególne moduły tych warstw, składające się na nie klasy i inne elementy kodu. 
W ten sposób pokazana zostaje architektura silnika. W rozdziale [3] opisane są do¬ 
kładniej wybrane elementy silnika. Za pomocą rysunków, listingów w pseudokodzie 
i fragmentów shaderów w języku HLSL przedstawiony zostaje sposób realizacji wy¬ 
branych efektów graficznych zawartych w silniku, ich algorytmy i obliczenia, jakie im 
towarzyszą. Rozdział [4] zawiera kolorowe zrzuty ekranu prezentujące efekt końcowy 
działania poszczególnych elementów silnika. W rozdziale [5] znajduje się podsumowa¬ 
nie oraz wnioski końcowe, a także informacje o możliwościach rozbudowy przedsta¬ 
wionego silnika w przyszłości. 
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Architektura silnika 


System opisany w tej pracy podzielony jest na wyraźnie rozróżnione warstwy zgod¬ 
nie z pewnymi zasadami. Rysunek |2. 1| przedstawia strukturę kodu systemu. Każda 
warstwa niższa jest bardziej podstawowa i nie korzysta z warstw wyższych, które są 
bardziej wyspecjalizowane. Każda warstwa może korzystać tylko z warstw niższych. 
Dzięki temu warstwy bardziej podstawowe mogą być wykorzystywane bez warstw wyż¬ 
szego poziomu, co autor niejednokrotnie wykorzystał pisząc aplikację konsolową wy¬ 
łącznie z użyciem modułów bazowych czy też grę dwuwymiarową wyłącznie z użyciem 
modułów bazowych i szkieletu, bez silnika. Fizycznie każda z warstw posiada kod 
i dane zgromadzone w osobnym katalogu. 



Biblioteka bazowa H Eksportery 


Rys. 2.1. Struktura kodu systemu opisanego w tej pracy. 

Charakterystyka poszczególnych warstw systemu: 

• Biblioteka bazowa nosi w kodzie nazwę Common. Jest to zbiór plików źródłowych 
w C++ zapewniających podstawowe funkcje i klasy przydatne podczas progra¬ 
mowania różnego rodzaju aplikacji, w tym obsługę łańcuchów i konwersji, mo¬ 
duł matematyczny, hierarchię klas wyjątków do obsługi błędów, moduł do daty 
i czasu, moduł do programowania wielowątkowego, hierarchię klas strumieni, 
obsługę systemu plików czy logger. w przeciwieństwie do pozostałej części sys¬ 
temu, biblioteka modułów bazowych jest przenośna między systemami Windows 
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i Linux. 

• Szkielet nosi w kodzie nazwę Framework. Jest to kod zapewniający podsta¬ 
wową funkcjonalność aplikacji wykorzystującej renderowanie grafiki czasu rze¬ 
czywistego w DirectX. Obejmuje zagadnienia takie jak tworzenie okna Windows 
i inicjalizacja biblioteki Direct3D, obsługę wejścia z klawiatury i myszki, a także 
konsolę tekstową, manager zasobów wraz z hieararchią klas różnego rodzaju za¬ 
sobów Direct3D, moduł do renderowania grafiki 2D oraz system GUI. 

• Silnik nosi w kodzie nazwę Engine. Jest to najważniejsza i najbardziej złożona 
część całego systemu. Stanowi spójny podsystem zapewniający renderowanie 
grafiki 3D i tworzący w tym celu warstwę abstrakcji ponad bibliotekę Direct3D, 
dzięki której użytkownik może się posługiwać klasami reprezentującymi abstrak¬ 
cyjne pojęcia, takie jak scena, kamera, materiał czy encja, bez zajmowania się 
szczegółami implementacyjnymi. 

• Gra nosi w kodzie nazwę Client. Jest to najwyższa warstwa, implementująca 
logikę aplikacji i korzystająca w tym celu z funkcjonalności zapewnianej przez 
silnik, w kodzie dołączonym do pracy stanowią ją proste prototypy 5 gier róż¬ 
nego gatunku, których jedynym celem jest pokazanie możliwości graficznych 
silnika. Własna implementacja tej warstwy jest podstawowym zadaniem pro¬ 
gramisty, który ma zamiar użytkować silnik. 

• Narzędzia noszą w kodzie nazwę Tools. Jest to zbiór dodatkowych procedur 
przetwarzających różnego rodzaju dane potrzebne do pracy silnika. W kodzie 
dołączonym do pracy narzędzia te mają postać pojedynczej aplikacji konsolowej 
uruchamianej z wiersza poleceń z odpowiednimi parametrami (nie posiadającej 
interfejsu graficznego). Aplikacja ta potrafi przetwarzać tekstury, modele oraz 
mapy. 

• Eksportery noszą w kodzie nazwę Plugins. Jest to zbiór dodatkowego oprogra¬ 
mowania dołączanego do zewnętrznych narzędzi w celu zapewnienia kompaty¬ 
bilności z formatami plików używanymi przez silnik. W dołączonym kodzie eks¬ 
portery te mają postać wtyczek napisanych w języku Python, przeznaczonych do 
eksportowania grafiki trójwymiarowej z darmowego programu Blender to forma¬ 
tów pośrednich, przetwarzanych potem na formaty docelowe przez wspomniane 
wyżej narzędzia konsolowe. 

2.1. Podstawowe założenia 

Jako platforma wybrany został komputer typu PC i system Windows. Decyzja ta 
podyktowana była głównie osobistymi preferencjami autora, aczkolwiek jest też uza¬ 
sadniona w szerszym kontekście. O ile system Linux znajduje szerokie zastosowania 
w wielu dziedzinach informatyki, o tyle w branży gier komputerowych jego znaczenie 
jest niewielkie. Coraz większą rolę odgrywają natomiast w tej branży inne platformy 
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sprzętowe — konsole, np. Playstation 3, XBox360, Wii czy urządzenia przenośne. 
Jednakże pakiety programistyczne do nich nie są często dostępne publicznie. Dlatego 
platforma Windows jest dobrym wyborem. Należy przy tym dodać, że nowoczesne, 
rozbudowane silniki są często pisanie w sposób pozwalający na ich działanie na wielu 
platformach — w szczególności na PC oraz na konsolach. Silnik napisany na potrzeby 
tej pracy nie jest przenośny na inne platformy, co uprościło jego implementację. 

Bardzo ważne było określenie możliwości sprzętu graficznego, jakie zostaną użyte 
w silniku. Wybrany został Shader Model 2, dostępny na kartach począwszy od Ge- 
Force 5 (FX) w górę i ich odpowiednikach firmy ATI. Sprzęt graficzny rozwija się bardzo 
szybko i stosunkowo niewiele czasu potrzeba, aby nowe generacje chipów graficznych 
stały się standardem pośród domowych użytkowników. Równocześnie nadal wiele 
jest komputerów posiadających stare lub bardzo stare karty graficznej. Są to przede 
wszystkim komputery biurowe i domowe należące do tych użytkowników, którzy nie 
są pasjonatami gier. Rozsądne wymagania w tym względzie, jakie może mieć gra, 
zależą więc od rodzaju tej gry. Po produkcie najwyższej jakości z bardzo realistyczną 
grafiką można spodziewać się wysokich wymagań sprzętowych, podczas gry małe typu 
Casual powinny mieć raczej niskie wymagania sprzętowe. Trzeba dodać przy tym, że 
dobre silniki potrafią się zwykle dostosować do sprzętu, na którym zostają urucho¬ 
mione wyłączając niektóre efekty bądź też wybierając osobną, specjalnie przygotowaną 
dla niższej klasy sprzętu ścieżkę renderowania. Silnik napisany na potrzeby tej pracy 
nie posiada takiej możliwości (korzysta wyłącznie z Shader Model 2 i jego wymaga), co 
uprościło jego implementację. 

Jako język programowania wybrany został C++. O ile w informatyce ogólnie uży¬ 
wane bywają różne języki programowania i wiele z nich jest dużo popularniejszych 
i częściej stosowanych w pewnych dziedzinach (jak Java i C# w aplikacjach bizneso¬ 
wych), o tyle w branży gier komputerowych decyzja o wyborze języka C++ jest oczy¬ 
wista i nie wzbudza żadnych kontrowersji. Język ten pozwala programować w spo¬ 
sób względnie wygodny i na wysokim poziomie (dzięki wsparciu dla programowania 
obiektowego i stosunkowo rozbudowanej bibliotece standardowej), a równocześnie jest 
kompilowany do kodu natywnego pozwalając uzyskać najwyższą wydajność i najlep¬ 
sze wykorzystanie sprzętu, co ma pierwszorzędne znaczenie. 

Jako środowisko programistyczne wybrany został Microsoft Visual Studio 2005 
Professional. Środowisko to jest bardzo często używane przez profesjonalistów pro¬ 
gramujących w C++ i uchodzi za najlepsze jakie istnieje na platformie Windows dzięki 
wygodnemu edytorowi, debuggerowi i dobremu kompilatorowi. 

Jako biblioteka graficzna wybrany został DirectX 9.0c. Na platformie Windows 
istnieją dwie biblioteki graficzne pozwalające na renderowanie grafiki trójwymiarowej 
z użyciem akceleracji sprzętowej — DirectX i OpenGL. Obydwie mają taką samą wy¬ 
dajność i takie same możliwości (w praktyce udostępniają po prostu funkcjonalność 
karty graficznej). Obydwie są darmowe do użycia zarówno dla programisty, jak i użyt- 
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kownika. Tak więc wybór jednej z nich jest raczej kwestią osobistych preferencji. 
Aczkolwiek podkreślić należy, że w zastosowaniu do poważnych gier na platformie PC 
częściej stosowany jest DirectX. 

Ponadto do napisania kodu przedstawionego silnika użyty został szereg innych na¬ 
rzędzi, w tym: GIMP (edytor grafiki bitmapowej), Blender (edytor grafiki 3D), Bitmap 
Font Generator (narzędzie do generowania tekstur przedstawiających znaki wybra¬ 
nej czcionki tekstowej), jEdit (edytor tekstu dla programistów), SVN (system kontroli 
wersji). 


2.2. Biblioteki zewnętrzne 

Do implementacji opisywanego systemu użyte zostały następujące biblioteki zewnętrzne: 

• Biblioteka standardowa C++, w szczególności łańcuchy znaków std: :string 
i kontenery STL takie jak std: :vector, std:: list, std: : map, 

• API systemowe, czyli funkcje udostępniane przez system operacyjny (przede 
wszystkim z nagłówka Windows . h), 

• FastDelegate — biblioteka realizująca brakujący w języku C++, a bardzo po¬ 
trzebny w niektórych zastosowaniach element składniowy — delegaty (ang. De- 
legate, nazywane też wskaźnikami na składowe — ang. Pointer to Member, sygna¬ 
łami i slotami — ang. Signal, Slot albo wywołaniami zwrotnymi — ang. Callback ), 
czyli wskaźniki na metody obiektów, 

• NVMeshMender — biblioteka firmy NVIDIA służąca do obliczania wektorów nor¬ 
malnych i stycznych w siatkach trójkątów, 

• zlib — biblioteka do kompresji danych w pamięci algorytmem Deflate oraz ob¬ 
sługi formatu pliku GZip. 


2.3. Architektura biblioteki bazowej 

Biblioteka bazowa to najniższa warstwa systemu. Stanowi kod w C++ zgromadzony 
w katalogu Common, w parach odpowiadających sobie plików źródłowych CPP i nagłów¬ 
kowych HPP. Każda taka para stanowi osobny moduł, przy czym niektóre moduły są 
ze sobą powiązane — wymagają do działania innych. Listę modułów podstawia tabela 

EU 

Biblioteka ta jest niezależna od całej reszty opisywanego systemu. Stanowi kod 
przydatny podczas pisania w języku C++ różnego rodzaju programów, choć powstała 
głównie z myślą o programowaniu gier. Jej aktualna wersja, oznaczona numerem 
iteracji 7, powstawała od połowy 2006 roku. 

Biblioteka bazowa została też opublikowana w Internecie za darmo, na licencji 
GNU LGPL, pod nazwą CommonLib. 
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Tablica 2.1. Lista modułów biblioteki bazowej. 


Base 

Moduł podstawowy 

Config 

Obsługa plików konfiguracyjnych 

DateTime 

Obsługa daty i czasu 

Dator 

Tekstowy dostęp do zmiennych różnego typu 

Error 

Hierarchia klas wyjątków do obsługi błędów 

Files 

Obsługa systemu plików 

FreeList 

Szybki alokator pamięci 

Logger 

Rozbudowany mechanizm logowania komunikatów 

Math 

Biblioteka matematyczna 

Profiler 

Klasa służącą do mierzenia wydajności 

Stream 

Hierarchia klas strumieni binarnych 

Threads 

Biblioteka do wielowątkowości i synchronizacji 

Tokenizer 

Prosty parser plików tekstowych 

ZlibUtils 

Obiektowa otoczka na bibliotekę kompresji zlib 


Podstawowe założenia Większość z wymienionych założeń jest wspólna dla kodu 
całego systemu. W przeciwieństwie do reszty systemu, biblioteka jest przenośna mię¬ 
dzy platformami Windows i Linux. Założenie to zostało podyktowane chęcią wykorzy¬ 
stania biblioteki także do napisania aplikacji serwerowej (serwera gry), która powinna 
działać na platformie uniksowej. Biblioteka ma niewiele zewnętrznych zależności. 
Używa wyłącznie biblioteki standardowej C++, API systemowego, a opcjonalny moduł 
ZlibUtils dodatkowo biblioteki zlib. Do przechowywania wszelkich łańcuchów teksto¬ 
wych używany jest typ std: : string z biblioteki standardowej C++. Nie jest to wybór 
optymalny ze względów wydajnościowych, ale zapewnia większą wygodę i bezpieczeń¬ 
stwo, niż używanie surowego wskaźnika do tablicy znaków typu char*. Do obsługi 
błędów używany jest mechanizm wyjątków C++ własnego typu, klas zapewnianych 
przez moduł Error. Biblioteka pisana jest z myślą o jak największej wydajności, ale 
nie kosztem bezpieczeństwa ani wygody używania. Korzysta z zaawansowanych moż¬ 
liwości języka C++ takich jak częściowa specjalizacja szablonów, dlatego wymaga do¬ 
brego kompilatora C++, zgodnego ze standardem. Testowana była na kompilatorach 
Visual C++ 2005 oraz GCC 4. Wszystkie elementy zgromadzone są w przestrzeni nazw 
common. Wersja biblioteki dołączona do pracy nie wspiera Unikodu. Polega na roz¬ 
miarze, a nawet budowie bitowej typów atomowych takich jak znaki, liczby całkowite 
i zmiennoprzecinkowe. Przez to nie nadaje się do użycia na platformach z inną kolej¬ 
nością bajtów czy 64-bitowych. 

Moduł Base Moduł bazowy to kod zgromadzony w plikach Common\Base . hpp 
i Common\Base. cpp. Nie używa on żadnego innego modułu, za to każdy inny moduł 
i każdy plik źródłowy całego systemu może i powinien używać jego włączając do kodu 
stosowny nagłówek. Zapewnia różnorodne możliwości, których zdaniem autora bra¬ 
kuje w bibliotece standardowej C++, a które są przydatne podczas programowania. 
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Poniższy opis nie wyczerpuje wszyskich elementów tego modułu, a jedynie te ważniej¬ 
sze i bardziej godne uwagi. Pełną listę definiowanych symboli można znaleźć w pliku 
nagłówkowym. 

Moduł włącza nagłówek <string> z biblioteki standardowej C++ i deklaruje using 
std: :string; po to, aby typu łańcuchowego string można było używać wszędzie 
niczym typów wbudowanych. 

Moduł definiuje także za pomocą typedef podstawowe typy całkowitoliczbowe 
o jawnie określonej długości: intl, int2, int4, int8, uintl, uint2, uint4, uint8. 
Przy intensywnym wykorzystaniu plików binarnych, a w przyszłości może także trans¬ 
misji sieciowej nie sposób uciec od wyspecyfikowania długości poszczególnych danych 
liczbowych, jak to robi standard języka C++ definiując np. typ int jako odpowiadający 
długości słowa maszynowego na danej platformie. Wiedzą o tym twórcy nowoczesnych 
języków takich jak C# czy Java, gdzie długość poszczególnych typów liczbowych jest 
stała i określona. 

Operator absolute_cast — ten prosty, sprytnie skonstruowany szablon funkcji 
imituje zachowanie operatorów rzutowania C++. Jego zadaniem jest uzupełnić brak 
w tym języku operatora, który pozwoliłby na dosłowną reinterpretację bitową war¬ 
tości dowolnego typu na dowolny inny typ. Zarówno stare rzutowanie w stylu C, 
jak i nowe operatory static_cast i reinterpret_cast nie potrafią na przykład po¬ 
traktować liczby typu f loat jako liczby typu unsigned int w sposób dosłowny, bez 
dokonywania konwersji numerycznej. Często stosowanym obejściem jest pobieranie 
adresu zmiennej, rzutowanie go na wskaźnik do innego typu i wyłuskanie otrzyma¬ 
nego wskaźnika. Równoważnym rozwiązaniem jest rzutowanie na referancję do innego 
typu. 

Oczywiście, potrzeba użycia takiej konstrukcji zachodzi niezwykle rzadko i nie 
można uznać jej za szczyt elegancji w programowaniu, ale bywa przydatna jako sztuczka 
optymalizacyjna pozwalająca na przykład na szybkie generowanie pseudolosowych 
liczb zmiennoprzecinkowych. Jej stosowanie jest też konieczne podczas używania bi¬ 
blioteki Direct3D do podawania liczb zmiennoprzecinkowych do funkcji 
IDirect3DDevice9::SetRenderState. 

template <typename destT, typename srcT> 
destT & absolute_cast(srcT &v) 

{ 

return re±nterpret_cast<destT&>(v); 

} 

Moduł dostarcza własnej implementacji inteligentnych wskaźników. Inteligentny 
wskaźnik (ang. Smart Pointer) to klasa, której zachowanie imituje wskaźnik, który 
jednak sam w swoim destruktorze zwalnia obiekt, na który wskazuje. Jest to przykład 
zastosowania wzorca RAII (ang. Resource Acąuisition Is Initialization ). 

Implementacja inteligentnych wskaźników wzorowana jest na bibliotece Boost. Au¬ 
tor chciał uniknąć użycia tej biblioteki w swoim projekcie, dlatego wiele przedstawio- 
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nych tu elementów dubluje jej funkcjonalność. Zaprojektowanie implementacji tego 
mechanizmu wymagało podjęcia wielu trudnych decyzji projektowych. Ostatecznie 
ich budowa jest prosta, ale rozszerzalna o politykę (ang. Policy — rozwiązanie spopu¬ 
laryzowane przez Andrei Alexandrescu (58)) określającą sposób zwalniania obiektu. 

Dostępne są cztery rodzaje inteligentnych wskaźników: scoped_ptr, shared_ptr, 
scoped_handle, shared_handle. Klasy typu „scoped-” posiadają wskazywany obiekt 
niejako na własność — nie pozwalają na kopiowanie wskaźnika i zawsze zwalniają go 
w destruktorze. Klasy typu „shared-” pozwalają na kopiowanie wskaźnika i posiadają 
licznik referencji. Wskazywany obiekt jest zwalniany, kiedy licznik referencji spada do 
zera (żaden inteligentny wskaźnik na niego nie wskazuje). Klasy typu ,,-ptr” przecho¬ 
wują wskaźnik do typu, którym są sparametryzowane. Klasy typu „-handle” przecho¬ 
wują bezpośrednio wartość typu, którym są sparametryzowane. Służą do przechowy¬ 
wania uchwytów, np. na otwarte pliki. 

Dostępne są trzy predefiniowane polityki zwalniania wskaźników: DeletePolicy 
używa operatora delete. DeleteArrayPolicy używa operatora delete [ ] (przezna¬ 
czony jest do tablic). ReleasePolicy dokonuje wywołania x->Release () ;. Prze¬ 
znaczone jest np. do obiektów COM. Ponadto dostępne są dwie predefiniowane poli¬ 
tyki zwalniania uchwytów. CloseHandlePolicy wywołuje funkcję CloseHandle (x) ; , 
natomiast DeleteOb jectPolicy wywołuje funkcję DeleteObject (x) ;. Użytkownik 
może łatwo pisać własne polityki zwalniania, a co za tym idzie używać tych inteligent¬ 
nych wskaźników do przechowywania uchwytów na różnego rodzaju zasoby. 

Poniższy listing przedstawia przykład użycia inteligenego wskaźnika: 

{ 

scoped_ptr<int, DeleteArrayPolicy> Ptr; 

Ptr.reset(new int[128]); 

UseArray(Ptr.get()) ; 

} // Tu tablica zostaje automatycznie zwolniona 

Moduł posiada bogaty zbiór funkcji operujących na łańcuchach znaków typu string. 
Pośród tych prostych wymienić można np. sprawdzanie, czy znak jest cyfrą, literą, 
znakiem alfanumerycznym, zamianę tekstu na duże lub małe litery. Oprócz nich 
dostępne są także liczne bardziej zaawansowane funkcje, w tym: 

• konwersja między rodzajami kodowania znaków końca wiersza (stosowany w Win¬ 
dows CR+LF, stosowany w Unix LF, stosowany w Mac CR), 

• konwersja między sposobami kodowania polskich znaków (obsługiwane strony 
kodowe to: Windows-1250, ISO-8859-2, CP852, UTF-8), 

• kodowanie Rot 13, 

• dopasowanie łańcucha do maski zawierającej symbole wieloznaczne (ang. Wild- 
cards ) ? i *, 

• przeszukiwanie pełnotekstowe, które zwraca wyliczoną trafność poszukiwania 
podanego podłańcucha w danym łańcuchu. 
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• obliczanie odległości edycyjnej między dwoma łańcuchami — Leuenshtein Di- 
stance, 

• funktor służący do sortowania łańcuchów w tzw. porządku naturalnym (gdzie 
liczby są interpretowane numerycznie, tak że Ala3 będzie wcześniej niż Ala22), 

• predykat porównujący łańcuchy bez rozróżniania wielkości liter. 

Moduł zawiera też zbiór funkcji operujących na łańcuchach w postaci ścieżek sys¬ 
temu plików. Obsługiwane są prawidłowo zarówno ścieżki systemu Windows, jak i Li- 
nux. Na przykład funkcje ExtractFilePath, ExtractFileName, ExtractFileExt 
pozwalają na pobieranie konkretnego fragmentu ścieżki. Najbardziej zaawansowane 
w tej grupie są funkcje RelativeToAbsolutePath i AbsoluteToRelativePath, które 
służą do zamiany ścieżki względnej na bezwzględną i odwrotnie. Implementacja funk¬ 
cji do operacji na ścieżkach inspirowana była w dużym stopniu podobnymi funkcjami 
w Delphi. 

Autor zaimplementował konwersje między łańcuchami znaków, a wartościami róż¬ 
nych typów, przede wszystkim liczbowych. Decyzja o własnej implementacji podjęta 
została z powodu niezadowolenia funkcjami wbudowanymi w bibliotekę standardową 
C — przede wszystkim ich bezpieczeństwem w sensie nieumiejętności zgłaszania błę¬ 
dów przekroczenia zakresu czy nieprawidłowych znaków. 

Konwersji między łańcuchami a typami całkowitoliczbowymi dowolnej długości do¬ 
konują szablony funkcji UnitToStr i IntToStr oraz StrToUint i StrToInt. Po¬ 
zwalają one na podanie podstawy systemu, co umożliwia używanie zarówno systemu 
dziesiętnego, jak i szesnastkowego, ósemkowego, binarnego i innych. Ponadto do¬ 
stępne są konwersje dla typów: zmiennoprzecinkowych float i double, znakowego 
char, logicznego bool i wskaźnikowego const vo±d*. Dodatkowo funkcje IntToStr2 
i UnitToStr2 potrafią dopełniać łańcuch do określonej długości zerami, a funkcja 
SizeToStr zwraca łańcuch z rozmiarem odpowiadającym podanej liczbie bajtów, wy¬ 
rażony w automatycznie dostosowanych jednostkach (B, KB, MB, GB itd.). Przykład 
użycia: 

uint4 i = 5; 
string s; 

UintToStr2 (&s, i, 3); // s zawiera "005" 

Na podstawie powyższych funkcji zbudowany został uogólniony, rozszerzalny me¬ 
chanizm konwersji łańcuchów na różne typy i odwrotnie, oparty na specjalizacji sza¬ 
blonów funkcji SthToStr i StrToSth. Dzięki niemu konwersja przebiega tak samo 
niezależnie od typu. Przykład: 

std::vector<int> v; 
v.push_back(1) ; 
v.push_back(2); 
v.push_back(3); 
string s; 

SthToStr (&s, v); // s zawiera "1,2,3" 
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Dalej na bazie tego mechanizmu powstał wygodny w użyciu mechanizm „formato¬ 
wania” łańcuchów zawierających wartości pobierane z wielu zmiennych, wzorowany 
na analogicznym z Boost. Choć jego użycie nie jest najoptymalniejszym wyborem, 
działa dużo szybciej niż Boost Format (który używa powolnych strumieni biblioteki 
standardowej C++). Przykład użycia: 

int i = 123; 
float f = 3.14f; 
string s = "abc"; 

string Out = Format("i=#, f=#, s=#") % i % f % s; 

// Out zawiera "i=123, f=3.14, s=abc" 


Bardzo ważny (np. w grach) jest precyzyjny pomiar czasu. Musi on być dużo 
dokładniejszy, niż co do sekundy, a najlepiej rzędu części milisekund. Moduł bazowy 
posiada przeznaczoną do tego klasę TimeMeasurer. Na platformie Windows używa 
ona licznika QPC (ang. Query Performance Counter) — funkcji 

QueryPerformanceFreąuency i QueryPerformanceCounter, a na platformie Linux 
funkcji gettimeofday. 

Ponadto dostępna jest funkcja Wait wstrzymująca bieżący wątek na określony czas 
(czekająca). Na platformie Windows używa funkcji systemowej Sleep, a na platformie 
Linux funkcji select. 

Bardziej zaawansowane funkcje matematyczne zgromadzone są w module mate¬ 


matycznym — zobacz p. 2.3, W opisywanym tutaj module bazowym umieszczone 
zostały jedynie te, które nie używają specjalnych typów takich jak wektory, macierze 
czy kwaterniony. 

W skład tej grupy wchodzą stałe matematyczne takie jak PI_X_2 ( 27 r), L0G2E (log 2 e) 
czy SQRT2 Proste funkcje inline uzupełniają braki biblioteki standardowej C 

i C++. Pośród nich znajdują się na przykład szablony funkcji safe_add, safe_sub 
i safe_mul służące do dodawania, odejmowania i mnożenia liczb całkowitych do¬ 
wolnej długości bez obawy o przepełnienie zakresu, funkcja round zaokrąlająca liczbę 
zmiennoprzecinkową do całkowitej zgodnie z zasadami matematyki, funkcja ceil_div 
dzieląca dwie liczby całkowite z zaokrągleniem wyniku w górę, porównywanie liczb 
zmiennoprzecinkowych z podaną tolerancją, znajdowanie najmniejszej potęgi dwójki 
większej lub równej podanej liczbie, szybkie podnoszenie liczby do potęgi całkowitej, 
funkcje trunc i f rac zwracające odpowiednio część całkowitą i część ułamkową poda¬ 
nej liczby zmiennoprzecinkowej, funkcja rozwiązująca równanie kwadratowe czy kilka 
funkcji do operacji na kątach. 

Na szczególną uwagę zasługują bardziej złożone funkcje. SmoothCD służy do wygła¬ 
dzania zmian pewnej wielkości (np. w czasie) wg metody Critically Damped Smoothing 
(591 . Dostępne są też funkcje generujące 1-, 2- oraz 3-wymiarowy szum Perlina. 

Dostępny jest także zbiór funkcji okresowych. Każdej z nich używa się w ten sam 
sposób — podając zmienną oraz parametry: wartość bazową, amplitudę, częstotliwość 
i fazę. Funkcje różnią się kształtem przebiegu. Dostępne są funkcje: sinusoidalna, 
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trójkątana, prostokątna, piłokształtna, odwrotna piłokształtna oraz prostokątna z re¬ 
gulowanym współczynnikiem wypełnienia. Funkcje takie są bardzo przydatne w pro¬ 
gramowaniu gier do obliczania zmian różnych wielkości w czasie (jak pozycja, orien¬ 
tacja, kolor, rozmiar, jasność, przezroczystość itd.). 

Moduł dostarcza własną implementację generatora liczb pseudolosowych — klasę 
RandomGenerator. Tworzenie własnych obiektów tej klasy pozwala na posiadanie 
prywatnego generatora dla konkretnego procesu obliczeniowego czy w konkretnym 
wątku. Z kolei ręczne ustawianie ziarna umożliwia otrzymanie generatora determini¬ 
stycznego. Domyślnie jako ziarno pobierany jest czas systemowy. 

Generowaniu wysokiej jakości liczb pseudolosowych poświęcone zostało wiele pu¬ 
blikacji. W programowaniu gier jednak na pierwszym miejscu stoi wydajność. Dlatego 
generowanie liczby typu uint4 zrealizowane zostało za pomocą jednego dodawania 
i jednego mnożenia, a generowanie liczby zmiennoprzecinkowej float — za pomocą 
sztuczki opartej na budowie bitowej tego typu. 

Generator zapewnia losowanie liczb całkowitych (z pełnego lub z podanego za¬ 
kresu), zmiennoprzecinkowych (z zakresu podanego lub domyślnego [0.0; 1.0]), warto¬ 
ści logicznych, dowolnie długich danych binarnych oraz liczb zmiennoprzecinkowych 
wg rozkładu normalnego (Gaussa). 

Szablon klasy Singleton ułatwia pisanie klas wg wzorca projektowego Single ton, 
czyli takich, które posiadają co najwyżej jedną instancję tworzoną w chwili pierwszego 
użycia. Korzysta z możliwości sparametryzowania szablonu klasą, która z niego dzie¬ 
dziczy. Dostarcza prywatnego pola przechowującego utworzoną instancję oraz metody 
statycznej Getlnstance do jej pobierania. Przykład użycia: 

class MyClass : public Singleton<MyClass> 

{ 

public: 

void Foo(); 

} ; 


MyClass::Getlnstance().Foo(); // Obiekt powstaje przy pierwszym użyciu 
MyClass::Getlnstance().Foo(); // Obiekt już istnieje 

Interpretacja przełączników podanych jako parametry wiersza poleceń podczas 
uruchamiania programu nie jest wbrew pozorom prostym zadaniem. W aplikacjach 
okienkowych w Windows cały wiersz poleceń ma postać pojedynczego łańcucha prze¬ 
kazywanego do funkcji WinMain. W aplikacjach konsolowych i w Linux wiersz poleceń 
jest rozbity na poszczególne parametry przekazywane w tablicy łańcuchów do funkcji 
main. Nadal jednak wyzwaniem pozostaje rozłożenie tych parametrów na poszcze¬ 
gólne przełączniki. W Linuksie dostępna jest przeznaczona do tego funkcja getopt, 
nie ma jej jednak w Windowsie. 

Dlatego po dogłębnych badaniach zachowania się wiersza poleceń w obydwu sys¬ 
temach autor zdecydował się na napisanie własnego parsera parametrów. Ma on 
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postać klasy CmdLineParser. Jako wejście akceptuje ona zarówno pojedynczy łań¬ 
cuch z całym wierszem poleceń (WinMain), jak i tablicę parametrów (main). Obsługuje 
przełączniki zapisane zarówno w konwencji Windowsa (/opcja), jak i Linuksa (-o 

—opcja). 

Użycie parsera wymaga najpierw zarejestrowania wszystkich dostępnych przełącz¬ 
ników. Każdy z nich może być pojedynczym znakiem lub dłuższym łańcuchem i każdy 
ma określoną flagę, czy przyjmuje dodatkowy parametr. Potem można rozpocząć od¬ 
czytywanie kolejnych elementów. Przełączniki jednoznakowe można łączyć, np. za¬ 
miast -a -b -c napisać można -abc. Dodatkowy parametr można zapisywać na 
różne sposoby: -a TEKST, -aTEKST, -a=TEKST. 

Oto przykład. Po zarejestrowaniu następujących przełączników: 

RegisterOpt(1, 'a', false); 

RegisterOpt (2, 'h', false); 

RegisterOpt (3, ' c', true); 

RegisterOpt(11, "AA", false); 

RegisterOpt(12, "BBB", true); 

parsować można następujący wiersz poleceń: 

-a -b -c param -abc="param" "-cparam" /AA —AA "/BBB"=param TEKST 
—BBB "param" 

Moduł Config W wielu różnego rodzaju programach zachodzi potrzeba wczytywania, 
a czasami też zapisywania ustawień konfiguracyjnych w plikach. Najczęściej są to 
pliki tekstowe, których zaletą jest czytelność i możliwość ręcznej edycji przez użyt¬ 
kownika za pomocą zwykłego edytora tekstu. 

Moduł do obsługi konfiguracji to kod zgromadzony w plikach Common\Conf ig. hpp 
i Common\Conf ig. cpp. Stanowi go zbiór struktur, które pozwalają na budowanie 
w pamięci reprezentacji pliku konfiguracyjnego i względnie szybki oraz wygodny do¬ 
stęp do przechowywanych przez niego danych. Zdefiniowane są trzy rodzaje struktur 
jako podklasy dziedziczące z klasy bazowej Item: 

• Klasa Value przechowuje pojedynczą wartość (zawsze typu łańcuchowego, ale 
może być konwertowana na różne typy danych — p. niżej). 

• Klasa List zawiera uporządkowaną sekwencję wartości typu łańcuchowego za¬ 
pamiętaną w wektorze STL. 

• Klasa Config zawiera mapę przechowującą zbiór par „Klucz —> Wartość”, gdzie 
klucz jest łańcuchem znaków, a wartość jest obiektem dowolnego z tych trzech 
typów. 

Dzięki temu w pamięci reprezentowane może być całe drzewo danych odwzorowu¬ 
jące plik konfiguracyjny. Klasa Config reprezentuje zarówno konfigurację jako całość, 
jak i dowolną jej gałąź. Posiada ona metody pozwalające na wczytywanie i zapisywanie 
konfiguracji do/z pliku, łańcucha lub dowolnego strumienia, a także do wygodnego 
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dostępu do zgromadzonych wartości za pomocą „ścieżki” wyrażonej jako łańcuch w po¬ 
staci Konf igurac ja/PodKonf igurac ja/Element. Ponadto jej metody pozwalają na 
automatyczną konwersję pamiętanych wartości łańcuchowych z/do wartości dowol¬ 
nych typów wspieranych przez mechanizm StrToSth i SthToStr opisany w rozdziale 


2.3, Prosty przykład użycia: 


common::Config cfg; 

cfg.LoadFromFile("Settings.cfg"); 

int Timeout; 

cfg.MustGetDataEx("GeneralSettings/Timeout", &Timeout); 


Moduł DateTime Obsługa daty i czasu pojmowanego w taki sposób, w jaki używają 
ich ludzie zgodnie z kalendarzem gregoriańskim jest dla programisty nie lada wyzwa¬ 
niem ze względu na złożoność tego kalendarza. Na przykład w celu obliczenia, jaki 
dzień tygodnia przypada dla określonej daty, algorytm polega najpierw na przelicze¬ 
niu tej daty na datę juliańską (JDN — ang. Julian Day Number). 

Istnieje wiele dostępnych API do obsługi daty i czasu. Na przykład biblioteka stan¬ 
dardowa C definiuje typy takie, jak struct tm, clock_t, time_t, WinAPI używa do 
reprezentowania czasu typów SYSTEMTIME, FILETIME i DWORD. Moduł do obsługi daty 
i czasu dostarcza też biblioteka Boost. Autor zdecydował się na zaimplementowanie 
własnej biblioteki tego typu. Implementacja zaprezentowana tutaj wzorowana jest 
na module datetime z biblioteki wxWidgets. Stanowi ją kod zgromadzony w plikach 
Common\DateTime . hpp i Common\DateTime . cpp. 

Moduł definiuje szereg typów reprezentujących różnego rodzaju wartości związane 
z datą i czasem. Dostępne są konwersje między tymi typami, jak również konwersje 
tych typów do/z łańcuchów znakowych. Wiele z nich ma także przeładowane opera¬ 
tory pozwalając na intuicyjne dokonywanie wybranych operacji arytmetycznych (jak 
dodawanie, odejmowanie, mnożenie, porównania). 

• WEEKDAY to typ wyliczeniowy reprezentujący dzień tygodnia. 

• MON TH to typ wyliczeniowy reprezentujący miesiąc roku. 

• NAME_FORM to flagi bitowe reprezentujące sposób generowania nazw dla dni ty¬ 
godnia i miesięcy 

• DATESPAN reprezentuje odcinek czasu. Przechowuje osobne liczby całkowite dla 
lat, miesięcy, tygodni i dni. Można za jego pomocą przesuwać TMSTRUCT. 

• TIMESPAN reprezentuje odcinek czasu. Przechowuje liczbę całkowitą ze znakiem 
w milisekundach. Można za jego pomocą przesuwać DATETIME. 

• TMSTRUCT reprezentuje moment czasu. Przechowuje osobne pola: dzień, miesiąc, 
rok, godzina, minuta, sekunda, milisekunda. Pamięta także dzień tygodnia, 
który wyliczany jest przy pierwszym odczytaniu (pole mutable). 

• DATETIME reprezentuje moment czasu. Przechowuje liczbę milisekund od „epoki 
uniksowej”, czyli 1 stycznia 1970. 
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Moduł Dator Moduł ten stanowi kod zgromadzony w plikach Common\Dator. hpp 
i Common\Dator. cpp. „Dator” to obiekt otaczający pojedynczą wartość jakiegoś typu 
i dający dostęp do jej zapisu i odczytu poprzez łańcuch tekstowy. Przechowuje wskaź¬ 
nik do tej wartości. Dator działa dla wszystkich typów obsługiwanych przez SthToStr 
i StrToSth (patrz p. |2.3) . Można też tworzyć własne specjalizacje. Wszystkie datory 
parametryzowane różnymi typami mają wspólną klasę bazową GenericDator z wir¬ 
tualnymi metodami SetValue i GetValue. 

Ponadto dostępna jest klasa DatorGroup, która przechowuje w swoim wnętrzu 
i zarządza kolekcją dowolnego rodzaju datorów identyfikowanych po nazwach. Może 
ona stanowić bazę dla utworzenia prostej tablicy właściwości (ang. Property Grid) 
— kontrolki dającej jednolity dostęp do kolekcji wartości różnego typu, odgrywającej 
coraz większą rolę w różnego rodzaju edytorach graficznych, również w branży gier 
komputerowych. Przykład użycia: 

int I = 123; 
float F = 10.5f; 
common::DatorGroup DG; 

DG. Add( "St rength", & I) ; 

DG. Add ("Life" , &F) ; 

DG.SetValue("Strength" , "124"); // Teraz I wynosi 124. 

string s; 

DG.GetValue("Life", &s); // Teraz s wynosi "10.5". 

Moduł Error Moduł ten stanowi kod zgromadzony w plikach Common\Error. hpp 
i Common\Error. cpp. Składa się na niego hierarchia klas przeznaczonych do uży¬ 
cia jako wyjątki C++. Zapewnia w ten sposób ujednolicony system zgłaszania błędów 
w kodzie, na który należy „przetwarzać” błędy raportowane na różne sposoby przez 
różne używane biblioteki. Modułu tego używją też inne moduły biblioteki bazowej (jak 
Files czy Stream) oraz pozostała część opisywanego w tej pracy kodu. 

W grach komputerowych, w przeciwieństwie do innego typu aplikacji, błędy nigdy 
nie powinny wystąpić. Jeśli błąd wystąpi, program najczęściej kończy swoje działanie. 
Ponadto obsługa błędów w C++ spowalnia wykonywanie kodu, co ma kluczowe zna¬ 
czenie w tej dziedzinie. Dlatego profesjonaliści z tej branży często całkowicie wyłączają 
obsługę wyjątków C++ w opcjach kompilatora. 

Z drugiej jednak strony, dobre raportowanie błędów ma bardzo duże znaczenie na 
etapie powstawania kodu. Na przykład użycie wartości niezainicjalizowanej (gdyż nie 
udało się jej wczytać z pliku konfiguracyjnego) owocuje dziwnym i nieprzewidywalnym 
zachowaniem programu, a próba użycia wskaźnika do obiektu, którego nie udało 
się utworzyć, zakończy się błędem ochrony pamięci. Takie błędy dużo trudniej jest 
zidentyfikować i naprawić, niż gdyby kod każdorazowo sprawdzał powodzenie operacji 
(szczególnie takich jak wszelkie wejście-wyjście i tworzenie różnego rodzaju zasobów) 
oraz raportował ewentualne błędy w czytelny sposób. Dlatego autor zdecydował się 
jednak na użycie wyjątków w swoim kodzie. 
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Powstaje pytanie, jakie informacje powinien nieść wyjątek? Wykonywanie wszel¬ 
kiego kodu opiera się na stosie wywołań i rodzaj błędu możnaby raportować bądź to 
z miejsca, w którym powstaje (najniższy poziom), bądź też z miejsca, w którym zo¬ 
staje przechwycony (najwyższy poziom). Zdaniem autora żadne z tych podejść nie 
dostarcza wystarczająco dużo informacji potrzebnych do zidentyfikowania przyczyny 
błędu. Jeśli na przykład błąd powstaje w kodzie wczytującym plik konfiguracyjny, 
zarówno komunikat najniższego poziomu — „Nie można skonwertować łańcucha na 
liczbę”, jak i komunikat najwyższego poziomu — „Nie można uruchomić programu” 
— nie daje pełnego obrazu zaistniałej sytuacji. Dostarczyć go może dopiero w miarę 
kompletny stos wywołań, jak na przykład: 

Nie można uruchomić programu. 

Nie można wczytać pliku konfiguracyjnego "ConfigOl.cfg". 

Błąd składni: wiersz 12, kolumna 3. 

Nie można skonwertować łańcucha na liczbę. 

Istnieją mechanizmy pozwalające na otrzymanie stosu wywołań funkcji od sys¬ 
temu. Same nazwy funkcji nie są jednak wystarczające, bo podczas odwijania stosu 
przy zgłaszaniu błędu konieczne jest niejednokrotnie dodawanie dodatkowych infor¬ 
macji, takich jak nazwa pliku, numer wiersza i kolumny w tekście i inne dane klu¬ 
czowe dla zidentyfikowania miejsca, w którym wystąpił błąd. Dlatego autor zdecy¬ 
dował się umieścić w klasie bazowej wyjątku Error cały stos łańcuchów znakowych 
niosących komunikaty o przyczynach błędu. 

Oprócz możliwości zgłoszenia błędu poprzez rzucenie wyjątku z utworzonego 
obiektu odpowiedniej klasy, potrzebna jest możliwość dopisania nowych komunika¬ 
tów podczas odwijania stosu. Można to zrobić za pomocą słowa kluczowego catch 
przyjmującego referencję do obiektu wyjątku, dopisania komunikatu do tego obiektu 
i jego dalszego rzucenia instrukcją throw; . Aby uprościć to zadanie, moduł posiada 
zdefiniowane makra, w tym ERR_TRY, ERR_CATCH, ERR_CATCH_FUNC. 

W językach gdzie używanie wyjątków do obsługi błędów jest standardem (np. Java, 
C#), hierarchia klas wyjątków odzwierciedla zwykle rodzaje błędów. W niniejszym 
kodzie jednak nie ma potrzeby wyłapywania tylko wyjątków wybranego rodzaju, po¬ 
nieważ prawie wszystkie błędy są obsługiwane na najwyższym poziomie i powodują 
zakończenie programu. Dlatego dziedziczenie zostało wykorzystane do wyprowadze¬ 
nia klas wyjątków różniących się sposobem powstania. Są to klasy niepolimorficzne, 
a ich jedynym zadaniem jest dostarczenie konstruktora, który potrafi przetworzyć błąd 
zgłaszany na sposób charakterystyczny dla danej biblioteki na jednolitą reprezenta¬ 
cję za pomocą wyjątków opisywanego modułu. I tak, klasa bazowa Error zapewnia 
zgłaszanie błędów własnych, podczas gdy na przykład klasa DirectXError przyjmuje 
w konstruktorze dodatkowo kod błędu typu HRESULT zwrócony przez funkcję DirectX 
i automatycznie pobiera komunikat błędu na podstawie tego kodu. Analogicznie dzia¬ 
łają inne klasy wyjątków dostosowane do sposobu zgłaszania błędów przez różne bi¬ 
blioteki: 
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1. Error — klasa bazowa przeznaczona do zgłaszania błędów własnych. 

2. ErrnoError — klasa przeznaczona do zgłaszania błędów na podstawie kodu 
errno, używanego przez funkcje biblioteki standardowej C i API systemu Linux. 
Automatycznie pobiera kod i komunikat błędu ze zmiennej errno. 

3. Win32Error — klasa przeznaczona do zgłaszania błędów biblioteki Windows API. 
Automatycznie pobiera kod i komunikat błędu z funkcji GetLastError. 

4. SDLError — klasa przeznaczona do zgłaszania błędów biblioteki SDL. 

5. OpenGLError — klasa przeznaczona do zgłaszania błędów biblioteki OpenGL. 

6. FmodError — klasa przeznaczona do zgłaszania błędów biblioteki dźwiękowej 
FMOD. 

7. DirectXError — klasa przeznaczona do zgłaszania błędów biblioteki DirectX. 

8. WinSockError — klasa przeznaczona do zgłaszania błędów biblioteki WinSock 
(będącej częścią Windows API). 

9. DevILError klasa przeznaczona do zgłaszania błędów biblioteki DevIL (przezna¬ 
czonej do obsługi różnych graficznych formatów pliku). 

10. AVIFileError — klasa przeznaczona do zgłaszania błędów biblioteki AVI File 
(będącej częścią Windows API). 

Przykład: 

void RobCosO 

{ 

ERR_TRY; 

throw common::Error("Jakiś błąd"); 

ERR_CATCH_FUNC; 


void WczytajKonfiguracje(const string SNazwaPliku) 

{ 

ERR_TRY; 

RobCos(); 

ERR_CATCH("Nie można wczytać pliku: " + NazwaPliku); 


void UruchomProgram() 

{ 

ERR_TRY; 

WczytajKonfiguracje("Config.dat") ; 
ERR_CATCH("Nie można uruchomić programu"); 


void Test () 

{ 

try 

{ 

UruchomProgram() ; 

} 

catch (const common::Error &e) 

{ 

string Message; 
e.GetMessage_(&Message) ; 

MessageBox(g_MainWnd, Message.c_str(), "Mój program", 
MB_0K | MB_IC0NERR0R); 

} 

} 
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Powyższy przykład pokaże komunikat błędu podobny do tego: 

[test.cpp,1611] Nie można uruchomić programu 

[test.cpp,1602] Nie można wczytać pliku: Config.dat 

[test.cpp,1593] void _cdecl RobCos(void) 

Jakiś błąd 


Moduł Files Kod tego modułu zgromadzony jest w plikach Common\Files . hpp 
i Common\Files . cpp. Zapewnia przenośne (jak cała biblioteka bazowa) funkcje do 
obsługi systemu plików, a więc plików i katalogów. 

Klasa FileStream rozszerza hierarchię klas strumieni (zobacz p. 2.3) o strumień 
służący do obsługi plików dyskowych. Klasa DirLister służy do listowania zawarto¬ 
ści wybranego katalogu — leżących w nim plików i podkatalogów. 

Ponadto moduł dostarcza funkcji służących m.in. do zapisywania i odczytywania 
plików w całości (jako surowe dane binarne lub łańcuchy znaków), do pobierania 
i ustawiania właściwości plików (rozmiar, data i czas utworzenia, ostatniej modyfikacji 
i ostatniego dostępu), a także do tworzenia i usuwania plików oraz katalogów. 

Większość z tych funkcji posiada dwie wersje. Pierwsza raportuje powodzenie 
zwracając wartość typu bool, natomiast druga (której nazwa rozpoczyna się od Must) 
w przypadku niepowodzenia rzuca wyjątek. 

W celu zapewnienia jak najlepszej wydajności oraz jakości raportowanych błędów, 
moduł używa funkcji z biblioteki standardowej C, ale na platformie Windows tam 
gdzie to możliwe preferuje używanie funkcji WinAPI. 


Moduł FreeList Dynamiczna alokacja pamięci ze sterty nie należy do szybkich ope¬ 
racji. Oczywiście jest wielokrotnie szybsza niz na przykład wejście-wyjście do plików 
dyskowych. Jednak dokonywanie wielu alokacji w każdej klatce silnika może zna¬ 
cząco spowolnić cały program. 

Dlatego wielu programistów gier decyduje się na własną implementację alokacji 
pamięci. Jest to powszechne szczególnie na konsolach. Na platformie PC, ze względu 
na dużą ilość dostępnej pamięci i obecność pliku wymiany nie jest to aż tak potrzebne. 

Sytuacją, kiedy alokacja pamięci najbardziej spowalnia proces obliczeniowy jest 
tworzenie wielu małych obiektów — np. cząsteczek dla efektu cząsteczkowego czy 
węzłów drzewa dla struktury podziału przestrzeni. Tak się jednak składa, że alokację 
obiektów określonego typu, których rozmiar w pamięci jest stały i znany, można łatwo 
przyspieszyć stosując technikę listy wolnych elementów (ang. Free List) (60). 

Technika ta polega na zaalokowaniu większego bloku pamięci zdolnego pomieścić 
wiele elementów i przydzielaniu pamięci z fragmentów tego bloku. Wolne elementy 
tworzą listę łączoną jednokierunkową, dzięki której alokacja i zwalnianie odbywa się 
w czasie stałym 0(1). Sztuczką optymalizacyjną jest wykorzystanie pierwszych czte¬ 
rech bajtów wolnego elementu do pamiętania wskaźnika na następny wolny element, 
zamiast tworzenia osobnej listy. Od strony języka C++ implementację tej techniki, 
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działającą także dla własnych nietrywialnych klas, można wykonać używając opera¬ 
tora placement new oraz jawnego wywołania destruktora. 

Zalety alokatora opartego na Free List to szybsza alokacja i zwalnianie pamięci oraz 
lepsza lokalność odwołań, dodatkowo poprawiająca wydajność dzięki lepszemu wyko¬ 
rzystaniu pamięci podręcznej Cache. Wady natomiast, to konieczność utworzenia 
obiektu Free List, alokacja więcej pamięci niż to jest potrzebne (część pamięci się mar¬ 
nuje), niestandardowy sposób alokowania i zwalniania obiektów oraz, w przypadku 
typowej prostej implementacji, ograniczona z góry maksymalna liczba możliwych do 
zaalokowania elementów. 

Wszystkie opisane powyżej rozwiązania wykorzystane zostały w niniejszym mo¬ 
dule. Kod tego modułu znajduje się w pliku Common\FreeList. hpp. Dostarcza on 
dwie klasy. FreeList to podstawowy alokator, rezerwujący pamięć na z góry okre¬ 
śloną liczbę elementów. DynamicFreeList działa nieco wolniej, ale potrafi rezerwo¬ 
wać wiele bloków pamięci, dzięki czemu liczba elementów możliwych do zaalokowania 
za jego pomocą ograniczona jest wyłącznie przez system operacyjny. Oto przykłady 
użycia: 

// Rezerwuje blok 1024 elementów, 
common::FreeList<int> LI(1024); 

// Alokuje element bez jego lnicjalizacji 
int *Ptrl = LI.New(); 

// Alokuje element inicjalizując go konstruktorem int(), czyli zerem, 
int *Ptr2 = LI.New_ctor(); 

// Zwalnia zaalokowane elementy 
LI.Delete(Ptr2); 

LI .Delete(Ptrl) ; 

// Dynamiczna lista o rozmiarze pojedynczego bloku 128 elementów, 
common::DynamicFreeList<MyClass> L2 (128); 

// Alokacja obiektu z wywołaniem konstruktora dwuargumentowego 
MyClass *Obj = L2.New(l, 2); 

// Zwolnienie obiektu z wywołaniem destruktora 
L2.Delete(Obj); 

W celu empirycznego upewnienia się o zasadności stosowania tego modułu, au¬ 
tor przeprowadził eksperyment polegający na pomiarze czasu trwania następującego 
testu: Każdy test składał się z 10240 losowych operacji, z 90% szansy, że tą opera¬ 
cją będzie alokacja nowego elementu i 10% szansy, że tą operacją będzie zwolnienie 
jednego z zaalokowanych elementów. Dodatkowo na końcu następowało zwolnienie 
wszystkich zaalokowanych i niezwolnionych wcześniej elementów. Wyniki pokazuje 
tabela |2.2| oraz wykres |2.2j 


Moduł Logger Mianem loga (dziennika) określa się lokalizację (najczęściej plik tek¬ 
stowy), do której program zapisuje komunikaty informujące o jego stanie pracy, waż¬ 
nych zdarzeniach, błędach itd. Logowania używają różnego typu programy, szczegól¬ 
nie te nieposiadające okienkowego interfejsu użytkownika — np. aplikacje serwerowe 
oraz gry i silniki. Autor projektując opisany tutaj logger starał się, aby był on jak 
najbardziej uniwersalny, ogólny i nadawał się dobrze do wszystkich tych zastosowań. 
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Tablica 2.2. Wyniki pomiaru wydajności alokatorów modułu FreeList w porównaniu 
z domyślnym alokatorem systemu Windows. 


Konfiguracja 

Rozmiar elementu 

FreeList 

DynamicFreeList 

new i delete 

DEBUG 

4 B 

68.0636 ms 

184.441 ms 

78.8142 ms 

DEBUG 

1024 B 

69.3896 ms 

203.506 ms 

93.2942 ms 

RELEASE 

4 B 

7.8722 ms 

11.4786 ms 

17.0348 ms 

RELEASE 

1024 B 

9.1805 ms 

18.0729 ms 

24.0537 ms 



FreeList DynamicFreeList newi delete 


Rodzaj alokatora 


Rys. 2.2. Czas trwania eksperymentu alokacji pamięci różnymi metodami w konfiguracji 

RELEASE. 


Kod tego modułu zgromadzony jest w plikach Common\Logger . hpp 
i Common\Logger. cpp. W opisywanym module, logger jako cały system logowania 
jest zawsze jeden. Inicjalizuje się go funkcją CreateLogger, a finalizuje funkcją 
DestroyLogger. Można w nim rejestrować wiele obiektów logów, które będą zapisy¬ 
wały komunikaty do różnych lokalizacji. Można do niego zapisywać też różne rodzaje 
komunikatów. Głównym założeniem jest przy tym, że podział komunikatów na rodzaje 
jest zupełnie oddzielony od logów, do jakich mogą zostać wysłane. 

Obiekty logów reprezentują konkretne lokalizacje, do których mogą być zapisy¬ 
wane komunikaty. Można definiować własne klasy logów dziedzicząc z klasy bazowej 
ILog. Dostępne są predefiniowane typy: TextFileLog zapisuje komunikaty do pliku 
tekstowego. HtmlFileLog zapisuje komunikaty do pliku HTML. OstreamLog zapisuje 
komunikaty do strumienia biblioteki standardowej C++ (np. na konsolę systemową 
std: : cout). 

Komunikat powinien mieć, oprócz treści, również pewien określony typ. Może on 
reprezentować np. rodzaj komunikatu (diagnostyczny, debugowy, informacyjny), jego 
priorytet (informacja, ostrzeżenie, błąd) czy rodzaj nadawcy (od którego podsystemu 
pochodzi). Jako najbardziej ogólne rozwiązanie autor wyposażył zapisywany komu¬ 
nikat w liczbę całkowitą 32-bitową (unit4), której konkretna interpretacja zależy od 
użytkownika tej biblioteki. Liczba ta powinna być traktowana jako wzorzec bitowy, 
gdyż w loggerze określać można maski bitowe, na podstawie których komunikaty wy¬ 
syłane są do zera, jednego lub wielu spośród zarejestrowanych w nim logów. 
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Owa maska bitowa może być wykorzystana dodatkowo do poprzedzania wybranych 
rodzajów komunikatów określonym prefiksem, który jest dodawany na początku tre¬ 
ści komunikatu. Prefiks taki to dowolny ciąg znaków, a specjalne sekwencje są w nim 
zastępowane aktualną datą, czasem i dodatkowymi informacjami ustawianymi w log- 
gerze (silnik wykorzystuje je do podania bieżącego numeru klatki). Istnieje osobno 
jeden główny prefiks dodawany do wszystkich komunikatów i osobno lista prefiksów 
z przypisanymi maskami bitowymi dla określonych rodzajów komunikatów. Ponadto 
prefiksy można ustalać dla każdego loga osobno lub globalnie dla całego loggera, co 
powoduje ich dodanie w każdym z istniejących logów. Oprócz prefiksów tekstowych 
dodawanych na początku treści komunikatów, pewne rodzaje logów mogą posiadać 
własne mapowanie masek bitowych na dodatkowe parametry takie jak kolor czy po¬ 
grubienie danego komunikatu, jeśli takie formatowania są dostępne. 

Logger może pracować w sposób bardziej bezpieczny lub bardziej wydajny. W celu 
osiągnięcia najwyższej wydajności można włączyć tryb pracy z kolejką, w którym log¬ 
ger pracuje w osobnym wątku logując zakolejkowane komunikaty w swoim tempie. 
Ponadto pliki logów mogą pozostawać otwarte przez cały czas działania programu. 
Jednakże jeśli log ma za zadanie nieść informacje krytyczne dla zidentyfikowania 
przyczyny błędu i ostatnia taka informacja może się pojawić na chwilę przez awa¬ 
rią programu (np. błąd ochrony pamięci), konieczne jest większe bezpieczeństwo, aby 
mieć pewność, że komunikat zostanie załogowany zanim system operacyjny zamknie 
proces. Wówczas należy nie włączać trybu pracy z kolejką, a dla logów używających 
plików wybrać tryb, w którym po zalogowaniu każdego komunikatu następuje Flush 
lub nawet osobne otwarcie pliku. 

Poniższy kod ilustruje niektóre możliwości opisanego loggera: 

// lnicjalizacja loggera 
CreateLogger (false); 

// Pobranie obiektu loggera 
Logger & L = GetLogger(); 

// Utworzenie przykładowych logów 

TextFileLog *Logl = new TextFileLogCLogl.txt", FILE_MODE_NORMAL, 
EOL_CRLF); 

TextFileLog *Log2 = new TextFileLogCLog2.txt", FILE_MODE_NORMAL, 
EOL_CRLF); 

// Ustawienie masek bitowych dla poszczególnych logów 
L.AddLogMapping(OxFFFFFFFF, Logi); 

L.AddLogMapping(1, Log2); 

// Ustawienie prefiksów 
Logl->SetPrefixFormat("[%D %T %1] "); 

Logl->AddTypePrefixMapping (1, "(!) "); 

L.SetCustomPrefixlnfo (0, "Frame:123"); 

// Przykładowe logowanie komunikatów 
L.Log(l, "Komunikat 1"); // Trafi do Logi i Log2 

L.Log(2, "Komunikat 2"); // Trafi do Logi 

L.Log(3, "Komunikat 3"); // Trafi do Logi i Log2 
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// Finalizacja loggera 
DestroyLogger(); 

// Zwolnienie logów 
delete Log2; 
delete Logi; 

Komunikaty zapisane przez Logi będą wyglądały mniej więcej tak: 

[2006-08-18 21:52:28 Frame:123] (!) Komunikat 1 
[2006-08-18 21:52:28 Frame:123] Komunikat 2 
[2006-08-18 21:52:28 Frame:123] (!) Komunikat 3 


Moduł Math Kod tego modułu zgromadzony jest w plikach Common\Math. hpp 
i Common\Math. cpp. Jest to największy z modułów biblioteki bazowej. Dostarcza on 
typów i funkcji związanych z geometrią i stanowi podstawę dla wszelkich obliczeń 
w całym opisywanym systemie. Należy przy tym podkreślić, że moduł ten zawiera 
wyłącznie elementy przydatne w programowaniu gier i grafiki 3D, a nie jest ogólną 
biblioteką matematyczną. Różni się więc znacznie od bibliotek stosowanych np. w ob¬ 
liczeniach naukowych. Przykładowo, nie zawiera on klasy macierzy o dowolnym roz¬ 
miarze, a jedynie macierz 4x4, ponieważ takie właśnie macierze są stosowane do 
reprezentowania transformacji w przestrzeni 3D. 

Użytkownicy DirectX są w o tyle komfortowej sytuacji w porównaniu z użytkowni¬ 
kami OpenGL, że na wyposażeniu tej pierwszej — w D3DX —jest już rozbudowana 
biblioteka matematyczna. Opisany tu moduł w znacznym stopniu dubluje jej funk¬ 
cjonalność. Decyzja o napisaniu własnej implementacji podstawowych typów i funkcji 
zamiast skorzystania z oferowanych przez D3DX podyktowana była chęcią zapewnie¬ 
nia przenośności na platformę Linux, w której DirectX nie jest dostępny. Intencją 
autora była możliwość napisania w przyszłości aplikacji serwerowej, która musiałaby 
dokonywać obliczeń geometrycznych, a równocześnie pracowałaby w systemie unik- 
sowym nie mając dostępu do biblioteki DirectX. Zdefiniowane struktury są jednak 
zbudowane tak samo jak te z D3DX, a więc są z nimi binarnie kompatybilne. 

Kod tego modułu pisany był ze szczególną dbałością o wydajność. Nie używa on 
wyjątków modułu Error. Wszelkie dane o rozmiarze większym niż 4 bajty są zwracane 
przez funkcje za pomocą parametru wskaźnikowego, nie przez wartość. Jako liczby 
zmiennoprzecinkowe używany jest typ 32-bitowy pojedynczej precyzji — f loat. 

Podstawą modułu matematycznego są różne obiekty geometryczne, z których więk¬ 
szość posiada swoją reprezentację jako osobne struktury. Dla każdej z tych struktur 
zdefiniowany jest szereg przeładowanych operatorów, metod oraz funkcji globalnych, 
które nie są tutaj szczegółowo opisane. Każdy z nich daje się również skonwertować 
do/z łańcucha znaków za pomocą ujednoliconego mechanizmu SthToStr i StrToSth 


(p. rozdz. 2.3 


• Punkt 2D opisany liczbami całkowitymi reprezentuje struktura POINT_. Odpo¬ 
wiada ona typowi POINT z WinAPI i złożona jest z pól int x, y;. 
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• Punkt 2-, 3- i 4—wymiarowy opisany liczbami zmiennoprzecinkowymi reprezen¬ 
tują struktury odpowiednio VEC2, VEC3 i VEC4. Posiadają one pola f loat x, y; 
oraz dodatkowo z i w. Odpowiadają typom z D3DX: D3DXVECTOR2, D3DXVECTOR3 
i D3DXVECTOR4. Zdefiniowane jest wiele funkcji do operacji na tych wektorach, 
w tym iloczyn skalarny i wektorowy, obliczanie długości i odległości, normaliza¬ 
cja, interpolacja liniowa, rzutowanie, ortogonalizacja i inne. 

• Trójkąt w przestrzeni 3D nie posiada jawnej reprezentacji w postaci własnej 
struktury. Do jego opisania używane są trzy punkty typu VEC3. Zbiór funkcji 
wspierających trójkąty obejmuje m.in. operacje na współrzędnych barycentrycz- 
nych. 

• Promień (ang. Ray, inaczej półprosta w przestrzeni 3D) również nie posiada 
swojej reprezentacji jako osobnej struktury. Do jego opisania używane są dwie 
zmienne typu VEC3 — punkt początkowy oraz wektor kierunku (nazywane w ko¬ 
dzie RayOrig i RayDir, od ang. Origin i Direction). 

• Prostokąt 2D zbudowany z liczb całkowitych reprezentuje struktura RECTI. Po¬ 
siada ona pola int left, top, right, bottom; . Odpowiada strukturze RECT 
z WinAPI. 

• Prostokąt 2D zbudowany z liczb zmiennoprzecinkowych reprezentuje struktura 
RECTF. Posiada ona pola float left, top, right, bottom; . Istnieją funkcje 
testujące czy punkt lub inny prostokąt zawiera się w danym prostokącie, jak 
również liczące sumę i część wspólną dwóch prostokątów. 

• AABB (ang. Axis-Aligned Bounding Box, czyli prostopadłościan o krawędziach 
równoległych do osi układu współrzędnych) posiada reprezentację w postaci struk¬ 
tury BOX wyposażonej w pola opisujące jego dwa wierzchołki — o najmniejszych 

i o największych współrzędnych — VEC3 pl , p2;. 

• Kolor wraz z czwartym kanałem — Alfa oznaczającym przezroczystość — po¬ 
siada dwie reprezentacje. Struktura COLOR zbudowana jest z pojedynczej liczby 
całkowitej 4-bajtowej, której poszczególne bajty przechowują wartości czterech 
kanałów w zakresie [0; 255], Struktura COLORF posiada pola f loat R, G, B, A; 
reprezentujące poszczególne składowe jako liczby zmiennoprzecinkowe w zakre¬ 
sie [0.0; 1.0], Funkcje operujące na kolorach obejmują m.in. interpolację i kon¬ 
wersję do/z przestrzeni kolorystycznej HSB. 

• Płaszczyzna w 3D opisywana jest równaniem Ax+By+Cz+D = 0. Jej współczyn¬ 
niki float a, b, c, d; potrafi przechowywać struktura PLANE. Odpowiada 
ona typowi D3DXPLANE z D3DX. Tworzenie płaszczyzny polega zazwyczaj na po¬ 
daniu wektora normalnego i przykładowego punktu, który do niej należy bądź 
podaniu trzech należących do niej punktów. 

• Prosta na płaszczyźnie opisywana jest równaniem Ax + By + (7 = 0. Do re¬ 
prezentacji jej współczynników float a, b, c ; zdefiniowana została struktura 
LINE2D. 
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• Macierz 4x4 opisuje struktura MATRIX. Używana jest w geometrii obliczenio¬ 
wej do reprezentowania szerokiej klasy przekształceń w przestrzeni 3D. Jej pod- 
macierz 3x3 potrafi reprezentować przekształcenia liniowe — dowolną rotację, 
skalowanie, ścinanie, odbicie oraz dowolne złożenie tych przekształceń w okre¬ 
ślonej kolejności. Macierz 4x3 potrafi reprezentować przekształcenia afiniczne — 
te wymienione powyżej oraz translację. W macierzy 4x4, dzięki wykorzystaniu 
współrzędnych jednorodnych dodatkowo reprezentowane może być rzutowanie 
perspektywiczne, co wyczerpuje większość przekszałceń stosowanych w grafice 
3D (niemożliwe do opisania taką macierzą pozostają np. przekształcenia sfe¬ 
ryczne i paraboloidalne). Liczne funkcje związane z tą strukturą służą przede 
wszystkim do tworzenia macierzy reprezentujących poszczególne rodzaje prze¬ 
kształceń. 

• Kwaternion to rozszerzenie liczb zespolonych na wartość posiadającą 4 skła¬ 
dowe — float x, y, z, w;. Nie powinien być mylony z punktem we współ¬ 
rzędnych jednorodnych. Dlatego reprezentowania kwaternionów utworzona zo¬ 
stała osobna struktura — QUATERNION. Odpowiada ona typowi D3DXQUATERNI0N 
z D3DX. Kwaternion wykorzystywany jest w grafice 3D do opisywania dowol¬ 
nej rotacji lub orientacji i jest w tym zastosowaniu lepszy niż kąty Eulera czy 
macierz, ponieważ nie posiada zjawiska Gimbal lock oraz daje się łatwo inter¬ 
polować (SLERP — ang. Spherical Linear Interpolatioń). Kwaternion powstaje 
przez podanie wektora osi obrotu i kąta obrotu wokół tej osi. Możliwe jest jednak 
dowolne przechodzenie między opisem rotacji przez kąty Eulera, macierz rotacji 
lub kwaternion. Do wszystkich tych przekształceń dostarczone są odpowiednie 
funkcje. 

• Frustum to ścięty ostrosłup o podstawie prostokąta. Nie posiada eleganckiego 
polskiego tłumaczenia (w środowisku internetowym zaproponowany został ter¬ 
min „ściętosłup”). Kształt ten posiada znaczenie w grafice 3D, ponieważ opisuje 
obszar widoczny w kamerze stosującej rzutowanie perspektywiczne. Stąd bardzo 
istotna jest możliwość stwierdzenia, czy obiekt (a raczej jego uproszczona bryła 
otaczająca) przecina to pole widzenia, a tym samym czy wymaga narysowania 
na ekranie. Moduł dostarcza trzech różnych reprezentacji frustuma, między któ¬ 
rymi można przechodzić. Struktura FRUSTUM_PLANES opisuje frustum jako 6 
płaszczyzn. Struktura FRUSTUM_POINTS opisuje go jako 8 punktów. Struktura 
FRUSTUM_RADAR natomiast to tzw. reprezentacja radarowa 1611 . 

• Sfera lub kula w 3D nie posiada dedykowanej struktury. Opisywana jest jako 
punkt — pozycja środka oraz wartość skalarna oznaczająca promień: 

VEC3 SphereCenter; float SphereRadius;. 

Zbiór kilkudziesięciu funkcji oznaczonych jako liczące kolizje pozwala stwierdzać 
o zachodzeniu na siebie brył różnego rodzaju. Nie sposób opisać dokładnie ich wszyst¬ 
kich, bo temat liczenia kolizji sam w sobie stanowi obszerną dziedzinę. Praktycznie 
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każda z tych funkcji zawiera w swojej implementacji pewien sprytny algorytm pocho¬ 
dzący z jakiejś książki lub publikacji internetowej, a skompletowanie biblioteki tych 
funkcji kosztowało wiele czasu i pracy. Wiele z nich zostało opracowanych na podsta¬ 
wie 09 • Dokładne informacje o źródłach poszczególnych algorytmów znaleźć można 
w komentarzach w kodzie. 

Przykładowo, funkcja SweptBoxToBox sprawdza kolizję poruszającego się prosto¬ 
padłościanu z innym prostopadłościanem. Wykorzystuje w tym celu sumę Minkow- 
skiego. Funkcja TriangleToBox sprawdza, czy trójkąt w przestrzeni 3D przecina pro¬ 
stopadłościan. Wykorzystuje w tym celu twierdzenie o płaszczyznach rozdzielających 
(ang. Separating Axis Theorem) 162} . 

Dysk Poissona (ang. Poisson Disc, (63]) to takie rozmieszczenie punktów na płasz¬ 
czyźnie lub w przestrzeni, w którym pozycje tych punktów są losowe, ale żadna para 
punktów nie jest od siebie odległa o mniej niż określona stała granica. Taki rozkład 
punktów wykorzystywany bywa w różnych zastosowaniach, np. podczas próbkowa¬ 
nia przy śledzeniu promieni (Supersampling). Ma tę zaletę ponad regularną siatką 
punktów, że ich losowe rozmieszczenie zapobiega zjawisku aliasingu, natomiast jego 
zaleta w porównaniu z rozmieszczeniem zupełnie losowym polega na nieskupianiu się 
punktów w miejscach o większej lub mniejszej gęstości. 

Problem z zastosowaniem dysku Poissona polega na dużej złożoności obliczenio¬ 
wej generowania zbioru takich punktów. Dlatego dobrze jest przygotować wcześniej 
tablicę wypełnioną przykładowymi punktami o tym rozkładzie. Problemem jest jednak 
dostosowanie ich liczby do wymagań konkretnego zastosowania. 

Aby temu zaradzić, autor postanowił wygenerować zbiór punktów dysku Poissona 
wg następującego algorytmu: Losowane są punkty odległe od siebie nie mniej, niż 
o pewną dużą wartość. Po wielu nieudanych próbach dodania następnego takiego 
punktu wartość ta jest zmniejszana pozwalając na obecność punktów nieco bliżej sie¬ 
bie położonych. Proces jest powtarzany aż do wygenerowania pożądanej liczby punk¬ 
tów. 

Takie podejście pozwala otrzymać tablicę punktów, z których można wziąć N pierw¬ 
szych elementów i zawsze stanowić one będą poprawny dysk Poissona o wartości 
granicznej odległości tym większej, im mniejsze jest N. Dzięki temu te same ta¬ 
blice punktów zastosowane mogą być w różnych sytuacjach. Autor napisał specjalny 
program generujący takie tablice za pomocą kosztownych czasowo obliczeń, a na¬ 
stępnie zapisał je bezpośrednio w kodzie jako zbiory 100 1-, 2- i 3-wymiarowych 
punktów w zmiennych o nazwach odpowiednio P0ISS0N_DISC_1D, POISSON_DISC_2D 
i POISSON_DISC_3D. Proponowana nazwa dla takiego rozwiązania to „progresywny 
dysk Poissona” (ang. Progresswe Poisson Disc). 

Moduł Profiler Probier w informatyce oznacza narzędzie do analizowania pracy pro¬ 
gramu w celu zbadania jego wydajności, szczególnie znalezienia „wąskich gardeł”, któ- 
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rych optymalizacji warto poświęcić uwagę. Niniejszym moduł stanowi prostą imple¬ 
mentację profilera przeznaczonego do osadzania wprost w kodzie programu. Kod tego 
modułu zgromadzony jest w plikach Common\Prof iler . hpp i Common\Prof iler . cpp. 

Najważniejsza klasa — Profiler — posiada główną instancję w postaci zmien¬ 
nej globalnej g_Profiler. Można też tworzyć nowe obiekty tej klasy. Wewnętrzne 
używa ona stosu do monitorowania rejestrowanych w nim zagnieżdżonych operacji 
i mierzenia czasu ich trwania. Na podstawie takiego pomiaru, najlepiej powtórzonego 
wielokrotnie, powstaje „profil” — drzewiasta struktura danych opisująca czas trwania 
poszczególnych operacji i ich podoperacji składowych. Rejestrowania chwili rozpoczę¬ 
cia i zakończenia operacji dokonuje się wywołując metody odpowiednio Begin i End 
lub wygodniej, tworząc obiekt automatyczny za pomocą makra PROFILE_GUARD . Po 
zakończeniu wszystkich tych operacji można otrzymać drzewo z profilem zapisane do 
pojedynczego łańcucha znaków. Oto przykładowe wyjście generowane przez profiler: 

Operacja 1 : 14.92 ms (10) 

Operacja 2 : 46.8442 ms (10) 

Pod-operacja 1 : 31.2242 ms (10) 

Pod-operacja 2 : 15.4256 ms (10) 

Oczywiście taki moduł nie zastąpi w pełni prawdziwego zewnętrznego profilera ta¬ 
kiego jak AMD CodeAnalyst. Może jednak ułatwić w niektórych sytuacjach badanie 
wydajności poszczególnych operacji w pisanym kodzie. 


Moduł Stream Moduł Stream definiuje hierarchię klas strumieni. Kod tego modułu 
zgromadzony jest w plikach Common\stream. hpp i Common\stream. cpp. W wielu pro¬ 
gramach odczuwalna jest potrzeba użycia ujednoliconego systemu strumieni, który 
pozwalałby na zapisywanie i odczytywanie danych bez uwzględniania miejsca, gdzie 
te dane trafiają (pamięć, plik na dysku itd.). Strumienie tego modułu są przeznaczone 
do danych binarnych. Ich interfejs jest wzorowany nieco na strumieniach z Delphi, 
C# i Java. Są za to zupełnie niepodobne do strumieni C++, które stanowią właściwie 
mieszankę strumieni danych binarnych z prostym parserem potrafiącym przetwa¬ 
rzać tekst na wartości różnego typu. Autor nie jest zwolennikiem takiego podejścia, 
dlatego do parsowania plików tekstowych przeznaczył osobny moduł — Tokenizer 
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Strumienie tego modułu nie są zaprojektowane z myślą o jak najwyższej wydaj¬ 
ności. Klasy są polimorficzne i używają metod wirtualnych, a błędy wejścia-wyjścia 
są zgłaszane poprzez wyjątki modułu Error. Nie ma to jednak aż tak dużego znacze¬ 
nia, ponieważ przetwarzanie danych przez procesor i tak jest wielokrotnie wolniejsze, 
niż ich zapis i odczyt z dysku twardego czy nośnika optycznego. Oczywiście zawsze 
trzeba pamiętać o zasadzie unikania zapisów i odczytów pojedynczych bajtów na rzecz 
dłuższych bloków pamięci. 

Jedną z kluczowych decyzji projektowych było utworzenie osobnych klas bazowych 
reprezentujących strumienie posiadające i nieposiadające kursora (bieżącej pozycji do 
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zapisywania/odczytywania danych, którą można zmieniać) i/lub strumieni wejścio¬ 
wych i wyjściowych. Ostatecznie wybrany został ten pierwszy podział. Klasa bazowa 
wszystkich strumieni — Stream — posiada podklasę SeekableStream wzbogacającą 
ją o metody do odczytywania i zapisywania długości danych oraz pozycji kursora. 
Zdaniem autora jest to wybór oczywisty, ponieważ to czy strumień danego rodzaju 
posiada kursor (np. plik dyskowy) czy też go nie posiada (np. gniazdo sieciowe) jest 
rzeczą z góry znaną, podczas gdy możliwość zapisywania i/lub odczytywania danych 
jest często tylko kwestią odpowiedniej flagi, mówiącej np. o otwieraniu pliku w trybie 
tylko do odczytu bądź tylko do zapisu. 

Poniższy listing prezentuje wykaz metod klasy bazowej Stream, dla skrócenia po¬ 
zbawionych komentarzy objaśniających z pliku nagłówkowego. Pozwalają one na za¬ 
pisywanie i odczytywanie zarówno dłuższych fragmentów danych binarnych, jak i po¬ 
jedynczych wartości różnego typu. 

virtual void Write(const void *Data, size_t Size); 
virtual void Flush(); 

template ctypename T> void WriteEx(const T &x) 

{ return Write(&x, sizeof(x)); } 

void WriteStringl(const string &s); 
void WriteStringż (const string &s); 
void WriteString4(const string &s); 
void WriteStringF(const string &s); 
void WriteBool (bool b); 

virtual size_t Read(void *Data, size_t MaxLength); 
virtual void MustRead(void *Data, size_t Length); 
virtual bool End(); 

virtual size_t Skip(size_t MaxLength); 
template ctypename T> void ReadEx(T *x) 

{ MustRead(x, sizeof(*x)); } 

void ReadStringl(string *s); 
void ReadStringż(string *s); 
void ReadString4(string *s); 

void ReadStringF(string *s, size_t Length); 
void ReadStringToEnd(string *s); 
void ReadBool (bool *b); 
void MustSkip(size_t Length); 

size_t CopyFrom(Stream *s, size_t Size); 
void MustCopyFrom(Stream *s, size_t Size); 
void CopyFromToEnd(Stream *s); 

Metody z grupy WriteStringN i ReadStringN zapisują i odczytują łańcuchy zna¬ 
ków poprzedzone odpowiednio 1, 2 lub 4 bajtami określającymi jego długość. Na 
uwagę zasługują również szablony metod WriteEx i ReadEx, które potrafią zapisywać 
wartości dowolnego typu automatycznie pobierając ich rozmiar. 

Poniższy listing prezentuje listę metod, o jakich klasę strumienia wzbogaca pod- 
klasa SeekableStream. 

virtual size_t GetSizeO; 

virtual int GetPosO; 

virtual void SetPos (int pos); 

virtual void SetPosFromCurrent(int pos); 

virtual void SetPosFromEnd(int pos); 
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virtual void Rewind(); 
virtual void SetSize(size_t Size); 
virtual void Truncate () ; 
virtual void Clear(); 

Z klasy bazowej OverlayStream wyprowadzone są z kolei tzw. nakładki na stru¬ 
mienie. Nakładka jest strumieniem, który przechowuje wskaźnik do innego strumie¬ 
nia i zapisuje/odczytuje dane do/z niego, a pośrednicząc w ich przesyłaniu przetwarza 
je przy tym w określony sposób — np. kodując czy kompresując. 

Oprócz tych klas podstawowych, moduł definiuje również szereg klas pochodnych 
pełniących już konkretne funkcje. Oto lista wszystkich klas strumieni z modułu 
Stream: 

• Stream — klasa bazowa strumieni. 

• SeekableStream — klasa bazowa strumieni z obsługą długości i kursora. 

• CharWriter — klasa przyspieszająca zapisywanie do strumienia po znaku. 

• CharReader — klasa przyspieszająca odczytywanie ze strumienia po znaku. 

• MemoryStream — strumień do bloku pamięci o stałym rozmiarze. 

• VectorStream — strumień do samorozszerzającego się bloku pamięci. 

• StringStream — strumień do łańcucha typu string. 

• OverlayStream — klasa bazowa nakładek na strumienie. 

• CounterOverlayStream — nakładka zliczająca zapisywane i odczytywane dane. 

• LimitOverlayStream — nakładka ograniczająca ilość zapisywanych i odczyty¬ 
wanych danych. 

• MultiWriterStream — strumień zapisujący na raz do wielu strumieni. 

• Hash_Calc — strumień liczący hash. 

• CRC32_Calc — strumień liczący sumę kontrolną CRC32. 

• MD5_Calc — strumień liczący sumę kontrolną MD5. 

• XorCoder — strumień szyfrujący i deszyfrujący dane operacją XOR. 

• BinEncoder, BinDecoder — strumień kodujący/dekodujący dane binarne jako 
ciąg zer i jedynek. Każdy bajt zamienia na 8 znaków. 

• HexEncoder, HexDecoder — strumień kodujący/dekodujący dane binarne jako 
ciąg liczb szesnastkowych. Każdy bajt zamienia na 2 znaki. 

• Base64Encoder, Base64Decoder — strumień kodujący/dekodujący dane bi¬ 
narne w formacie Base64. Każde 3 bajty zamienia na 4 znaki. 

Moduł Stream definiuje też strukturę MD5_SUM reprezentującą sumę kontrolną 
MD5, a także jej konwersję do i z łańcucha. Inne moduły — Files i ZlibUtils — rozsze¬ 
rzają hierarchię strumieni o nowe klasy. 

Moduł Threads Moduł Threads dostarcza przenośnych klas do wielowątkowości i syn¬ 
chronizacji. Kod tego modułu zgromadzony jest w plikach Common\Threads . hpp 
i Common\Threads.cpp. 
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Utworzenie biblioteki wspierającej programowanie równoległe, która byłaby prze¬ 
nośna na Windows i Linux, stanowi pewien problem. W każdym z tych systemów są 
bowiem używane inne wywołania (w Linuksie używana jest biblioteka pthreads, a Win¬ 
dows posiada własne funkcje systemowe). Te dwa API różnią się nie tylko nazwami 
funkcji, ale posiadają zupełnie inne prymitywy synchronizujące. Autorowi udało się 
jednak zaimplementować wszystkie z nich na obydwu platformach, emulując je w ra¬ 
zie braku natywnego wsparcia ze strony systemu za pomocą innych. Mechanizmy 


systemowe użyte do realizacji poszczególnych prymitywów pokazuje tabela 2.3 Pod¬ 
czas implementacji bardzo pomocna była książka l64l . Oto opis dostępnych klas: 


Tablica 2.3. Implementacja prymitywów synchronizujących modułu Threads na 

poszczególnych platformach. 



Windows 

Linux 

Mutex 

CRITICAL_SECTION, Mutex 

pthread_mutex_t 

Semaphore 

Semaphore 

sem_t 

Cond 

(emulowany) 

pthread_cond_t 

Barrier 

(emulowany) 

pthread_barrier_t 

Event 

Event 

(emulowany) 


• Thread to klasa bazowa wątku. Aby utworzyć swój wątek, należy po niej odzie¬ 
dziczyć, podobnie jak w języku Java. 

• Mutex (od ang. Mutually Exclusive) to obiekt synchronizujący zapewniający, że 
objętą nim sekcję krytyczną kodu wykonuje w danej chwili co najwyżej jeden 
wątek. Pozostałe, które próbują to zrobić, muszą poczekać. 

• Semaphore to semafor — obiekt synchronizujący, który posiada wewnętrzny licz¬ 
nik. Operacja V to podniesienie semafora, zwiększa licznik o 1. Operacja P to 
opuszczenie semafora, zmniejsza licznik o 1, a jeśli jego wartość wynosi 0, czeka 
aż inny wątek go podniesie. Semafor może zatem służyć do ograniczania liczby 
wątków mających jednoczesny dostęp do pewnego zasobu. 

• Cond to zmienna warunkowa (ang. Conditional Variable). Wątek może wywołać 
jej metodę Wait czekając tym samym, aż inny wątek wznowi jego działanie wy¬ 
wołując metodę Signal lub Broadcast. Zmiennej warunkowej używa się często 
w określony sposób w połączeniu z pewnym własnym warunkiem (stąd nazwa). 
Może służyć do realizacji wzorca monitora. Implementacja tego prymitywu pod 
Windows została opracowana na podstawie kodu biblioteki wxWidgets i z pomocą 

1651. 

• Barrierto bariera — obiekt synchronizujący, który może stanowić punkt syn¬ 
chronizacji dla określonej liczby równolegle wykonywanych wątków. Wywołanie 
metody Wait blokuje wątek do czasu, aż określona liczba wątków zostanie w ten 
sposób zablokowana. Dopiero wtedy wszystkie na raz zostają odblokowane. 

• Event (zdarzenie) to obiekt posiadający stan w postaci wartości logicznej. Może 
być w stanie ustawionym lub nieustawionym. Pośród jego metod znajduje się 
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czekanie aż zdarzenie przejdzie w stan ustawiony, jego przestawianie do stanu 
ustawionego lub nieustawionego. Zdarzenie może zostać utworzone w trybie, 
w którym samo przestawia się z powrotem na stan nieustawiony po odblokowa¬ 
niu czekającego na nim wątku. 

Moduł Tokenizer W profesjonalnej produkcji gier i silników, w której z tworzonego 
systemu informatycznego korzysta wiele osób i nie wszyscy z nich są programistami, 
ważne jest przygotowanie łatwych w użyciu narzędzi i edytorów wyposażonych w gra¬ 
ficzny interfejs użytkownika. W warunkach amatorskich jednak wystarczające jest, 
a przy tym dużo prostsze i szybsze do zrealizowania, zapisywanie pewnych informacji 
w specjalnie sformatowanych plikach tekstowych odczytywanych bezpośrednio przez 
program. Zachodzi więc potrzeba definiowania wielu takich formatów plików i ich 
łatwego parsowania w kodzie silnika. 

Do generowania parserów wykorzystywać można specjalne narzędzia takie jak lex 
i yacc. Interpretowanie plików tekstowych, czy to języków opisu czy też języków pro¬ 
gramowania, składa się zwykle z dwóch etapów — tokenizacji (rozbicia łańcucha zna¬ 
ków na tokeny) i parsowania (analizy składniowej). Zdaniem autora najwygodniejszym 
podejściem do tego zagadnienia jest dostarczenie gotowego tokenizera o interfejsie tak 
prostym, aby tworzenie parserów konkretnego języka z jego użyciem było wygodne. 
Ponadto, języki opisu przeznaczony do różnych formatów plików (np. do opisywania 
materiałów, konfiguracji programu, listy zasobów itd.) łatwiej jest opanować, jeśli 
wszystkie oparte są na podobnej składni. Dlatego powstał moduł Tokenizer. 

Jego kod znajduje się w plikach Common\Tokenizer . hpp i Common\Tokenizer . cpp. 
Zapewniana przez niego klasa Tokenizer przyjmuje w konstruktorze łańcuch lub 
strumień ze znakami do parsowania. Wywołanie metody Next odczytuje następny to- 
ken i zapamiętuje go w prywatnych polach klasy. Jego typ i wartość można stamtąd 
pobrać metodami takimi jak GetToken, GetString, GetUint4, GetFloat itd. Klasa 
zapewnia wiele dodatkowych metod ułatwiających parsowanie. Przykładowo, wywo¬ 
łanie metody Assertldentif ier sprawdza, czy ostatnio odczytany token jest identy¬ 
fikatorem o podanej treści. Jeśli nie jest, metoda rzuca wyjątek sygnalizujący błąd, 
automatycznie wypełniony odpowiednim komunikatem i wskazujący mejsce wystą¬ 
pienia błędu (numer znaku, wiersza i kolumny). 

Opisywany moduł rozbija tekst na tokeny wg składni podobnej do języka C i C++. 
Obsługiwane rodzaje tokenówto: symbole (np. +, $, .), identyfikatory (np. Abc), liczby 
całkowite i zmiennoprzecinkowe (np. 123, OxFF, -3.14), stałe znakowe i łańcuchowe 
(np. ' A' "ABC")- Sekwencje ucieczki i komentarze wyglądają tak samo, jak w języku 
C i C++. 

Tworzenie parsera zaprojektowanego wcześniej formatu tekstowego (języka opisu) 
z użyciem tego tokenizera jest bardzo proste. Na przykład jeśli plik wygląda tak: 
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{ 

Nazwał = "Wartości" 
Nazwa2 = "Wartość2" 

} 


Wówczas kompletna funkcja rozkładająca tekst na dane może wyglądać następująco: 

void ParseMyFormat(std::map<string, string> &Out, const string &In) 

{ 

Tokenizer t (&In, 0); 
t.Next(); 

t.AssertSymbol('{'); 
t.Next(); 

std: :pair<string, string> Item; 
while ( !t.QuerySymbol('}')) 

{ 

t.AssertToken(Tokenizer::TOKEN_IDENTIFIER); 

Item.first = t.GetString(); 
t.Next (); 

t. AssertSymbol ('='); 
t .Next (); 

t .AssertToken(Tokenizer: :TOKEN_STRING); 

Item.second = t.GetString (); 
t.Next (); 

Out.insert(Item) ; 

} 

t.Next (); 
t.AssertEOF () ; 

} 

Moduł ZlibUtils Ten dodatkowy, opcjonalny moduł jest nakładką na bibliotekę zlib. 
Jego kod znajduje się w plikach Common\zlibUtils . hpp i Common\zlibUtils . cpp. 
Zlib to biblioteka do kompresji danych algorytmem Deflate, używanym m.in. w for¬ 
matach plików PNG i GZ. Jej interfejs, mający postać zbioru kilku funkcji języka C, 
jest bardzo trudny do opanowania i poprawnego użycia. Dlatego zachodzi potrzeba 
obudowania go w bardziej wygodne, obiektowe nakładki. 

Moduł definiuje następujące klasy: 

• ZlibError to klasa wyjątku reprezentująca błąd zgłaszany przez bibliotekę zlib. 

• ZlibCompressionStream to strumień kompresji danych do formatu zlib. 

• GzipCompressionStream to strumień kompresji danych do formatu gzip. 

• ZlibDecompressionStream to strumień dekompresji danych z formatu zlib. 

• GzipDecompressionStream strumień dekompresji danych z formatu gzip. 

• GzipFileStream to strumień zapisu i odczytu pliku w formacie gzip (zalecane 
rozszerzenie: GZ). 


2.4. Architektura szkieletu 


Szkielet (ang. Framework) to warstwa dostarczająca podstawowej funkcjonalności 
potrzebnej w każdym programie korzystającym z Direct3D — w tym tworzenia okna 
Windows, inicjalizacji Direct3D, obsługi wejścia z klawiatury i myszki, zarządzania za¬ 
sobami. Składa się na niego kod zgromadzony w katalogu Framework. Listę modułów 
tej warstwy pokazuje tabela 2.4[ 
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Tablica 2.4. Alfabetyczna lista modułów szkieletu. 


AsyncConsole 

Asynchroniczna obsługa konsoli systemowej. 

D3dUtils 

Elementy wspomagające pracę z Direct3D. 

Framework 

Główny moduł — szkielet aplikacji. 

Gfx2D 

Moduł do rysowania grafiki 2D. 

GUI 

Podstawa systemu GUI. 

GUI_Controls 

Kontrolki systemu GUI. 

GUI_PropertyGridWindow 

Kontrolka PropertyGrid. 

Multishader 

Zasób shadera komplowanego warunkowo. 

QMesh 

Zasób siatki 3D z obsługą animacji szkieletowej. 

Res_d3d 

Klasy zasobów związanych z Direct3D. 

ResMngr 

Podstawowe klasy managera zasobów. 


Cały kod szkieletu i warstw wyższych (nazwanych Silnik i Gra) korzysta z mecha¬ 
nizmu nagłówka prekompilowanego (ang. Precompiled Header ), który znacznie przy¬ 
spiesza kompilację. Przeznaczone dla niego pliki to Framework\pch . hpp 
i Framework\pch.cpp. 

Szkielet korzysta z biblioteki bazowej, natomiast nie wymaga do działania warstw 
wyższych, w tym silnika. Dzięki temu może zostać wykorzystany w różnorodnych 
zastosowaniach — np. do wizualizacji naukowych, gier 2D i 3D. Nie jest przenośny — 
działa tylko w środowisku Windows. 

Moduł AsyncConsole Wiele silników (np. te użyte w grach Quake i Neverwinter Ni- 
ghts) posiada konsolę tekstową pozwalającą na wypisywanie komunikatów i wprowa¬ 
dzanie poleceń. Często jest to konsola rysowana we własnym zakresie ponad obrazem 
renderowanym przez silnik. Autor zdecydował się jednak na prostsze rozwiązanie — 
użycie dodatkowego okna standardowej konsoli systemowej. 

Funkcje do obsługi konsoli systemowej z biblioteki standardowej C (jak printf, 
scanf) czy C++ (jak std: :cout, std: :c±n) mają liczne ograniczenia. Nie wspierają 
obsługi kolorów, jak również nie pozwalają na pracę asynchroniczną (oczekiwanie na 
wprowadzenie polecenia blokuje program). 

Dlatego moduł AsyncConsole, którego kod zgromadzony jest w plikach 
Framework\AsyncConsole . hpp i Framework\AsyncConsole . cpp, do obsługi konsoli 
systemowej korzysta z funkcji WinAPI. Zdefiniowana w nim klasa AsyncConsole daje 
przez prosty interfejs dostęp do funkcji takich jak wypisywanie komunikatów wraz 
z obsługą kolorów, jak również sprawdzanie polecenia wpisanego przez użytkownika. 
Odbieranie poleceń jest asynchroniczne, tzn. użytkownik może wprowadzać tekst do 
konsoli w dowolnej chwili, a program może sprawdzać wprowadzone polecenia bez blo¬ 
kowania swojego wykonywania. Zostało to osiągnięte poprzez użycie osobnego wątku 
czekającego na polecenia. Klasa jest przy tym bezpieczna wątkowo umożliwiając rów¬ 
noczesny dostęp do konsoli różnym częściom programu. 
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Moduł D3dUtils Kod zgromadzony w plikach Framework\D3dUtils . hpp 
i Framework\D3dUtils. cpp to zbiór struktur i funkcji wspomagających pracę z bi¬ 
blioteką Direct3D. 

Kolekcja 16 struktur (takich jak np. VERTEX_XN2) stanowi definicję najczęściej 
używanych formatów wierzchołka. Każda z nich posiada pola odpowiadąjce swojej 
nazwie (np. tu X oznacza pozycję 3D, N wektor normalny, a 2 dwuwymiarowe współ¬ 
rzędne tekstury), jak również definiuje flagę bitową FVF (ang. Flexible Vertex Format) 
opisującą dany format wierzchołka. 

Szereg klas stanowi otoczkę na funkcje Direct3D zgodnie ze wzorcem RAII, czyli do¬ 
konując automatycznej finalizacji w swoim destruktorze. Ich użycie zapewnia mniej¬ 
sze ryzyko popełnienia przez programistę błędu polegającego na pominięciu finalizacji. 
Klasa RenderTargetHelper ustawia w urządzeniu Direct3D podany cel renderowa- 
nia (ang. Render Target) i/lub bufor głębokości i szablonu (ang. Depth-Stencil Buf- 
fer), a w destruktorze przywraca oryginalne ustawienia. Klasa D3dxBufferWrapper 
przechowuje wskaźnik do interfejsu ID3DXBuffer (używanego w Direct3D m.in. do 
zgłaszania komunikatów o błędach kompilacji shaderów) i automatycznie zwalnia go 
w destruktorze. Klasy VertexBuf ferLock i IndexBuf ferLock służą do blokowania 
buforów wierzchołków i indeksów, automatycznie odblokowując je w destruktorze. 

Kilka funkcji przeznaczonych jest do operowania na formacie wierzchołka FVF. 
Przykładowo CalcComponentSizesAndOf f sets potrafi obliczyć rozmiary i offsety po¬ 
szczególnych elementów wierzchołka (jak pozycja, wektor normalny, koordynaty tek¬ 
stury) na podstawie podanego formatu FVF. 

Moduł posiada także funkcje służące do konwertowania różnych typów wylicze¬ 
niowych używanych przez Direct3D do/z łańcuchów znaków. Mogą one stanowić 
pomoc przy implementowaniu wczytywania i zapisywania konfiguracji graficznej pro¬ 
gramu. Przykładowo, funkcja StrToD3dfmt zamieni łańcuchy o treści "A8R8G8B8" 
i "D3DFMT_A8R8G8B8 " na wartość stałej D3DFMT_A8R8G8B8. 

Moduł Framework Ten moduł, którego kod zgromadzony jest w plikach 
Framework\Framework.hpp i Framework\Framework.cpp, stanowi jakby podstawę 
całego programu. To do niego kierowane jest sterowanie z funkcji głównej WinMain, 
a w jego wnętrzu znajduje się pętla główna programu z obsługą komunikatów okna 
Windows. Wszystkie zdefiniowane w nim elementy zgromadzone są w przestrzeni 
nazw frame. Funkcje tego modułu to: 

• tworzenie, usuwanie, zarządzanie oknem Windows, 

• obsługa okna — sterowanie jego możliwościami, odbieranie komunikatów (ska¬ 
lowanie, minimalizacja, utrata aktywności itp.), 

• tworzenie, usuwanie, resetowanie obiektu Direct3D oraz urządzenia Direct3D, 

• obsługa utraty urządzenia D3D, 

• udostępnianie do użytku: uchwytu okna, obiektu D3D, urządzenia D3D, 
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• zmiana ustawień graficznych w czasie pracy, 

• przechwytywanie i obsługa błędów modułu Error, 

• obsługa pęli komunikatów, 

• obsługa wejścia z klawiatury i z myszy, 

• pomiar czasu i zliczanie FPS, 

• wczytywanie z pliku i zapisywanie do pliku ustawień graficznych. 


Poniższy listing prezentuje pola struktury opisującej ustawienia graficzne. 

struct SETTINGS 

{ 

uint4 BackBufferWidth; 
uint4 BackBufferHeight; 
u±nt4 RefreshRate; 

D3DF0RMAT BackBufferFormat; 
uint4 BackBufferCount; 

D3DMULTISAMPLE_TYPE MultiSampleType; 
uint4 MultiSampleQuality; 

D3DSWAPEFFECT SwapEffect; 

bool FullScreen; 

bool EnableAutoDepthStencil; 

D3DF0RMAT AutoDepthStencilFormat; 
bool DiscardDepthStencil; 
bool LockableBackBuffer; 
uint4 PresentationInverval; 

enum FLUSH_MODE { FLUSH_NONE, FLUSH_EVENT, FLUSH_LOCK }; 
FLUSH_MODE FlushMode; 

} ; 


Większość z tych pól odpowiada bezpośrednio polom struktury 
D3DPRESENT_PARAMETERS, opisującej ustawienia graficzne Direct3D, więc nie wymaga 
wyjaśnienia. Na uwagę zasługuje pole wyliczeniowe typu FLUSH_MODE. Oznacza ono 
sposób, w jaki program ma wymusić poczekanie na zakończenie renderowania przez 
kartę graficzną. Domyślnie takie czekanie nie powinno być wykonywane, gdyż spowal¬ 
nia tylko działanie całego programu. Autor napotkał jednak błąd w sterownikach gra¬ 
ficznych firmy NVIDIA, który w pewnych warunkach powodował, że karta nie dokań- 
czała renderowania całej wysłanej do niej geometrii przed zaprezentowaniem klatki 
na ekranie, co owocowało znikaniem bądź migotaniem niektórych obiektów albo ich 
fragmentów. 

Dlatego szkielet posiada możliwość włączenia wymuszonego czekania na skończe¬ 
nie pracy karty graficznej przed zaprezentowaniem nowej klatki na ekranie. Wartość 
FLUSH_EVENT powoduje użycie w tym celu obiektu zapytania IDirect3DQuery9 typu 
D3DQUERYTYPE_EVENT. Ponieważ w pewnych publikacjach pojawiają się głosy, że na¬ 
wet ta metoda nie zawsze jest skuteczna, wartość FLUSH_LOCK pozwala zastosować 
bardziej „brutalną” metodę korzystającą z blokowania specjalnie w tym celu stworzo¬ 
nych powierzchni (ang. Surface) 1661 . 

Sposób działania programów komputerowych można ogólnie podzielić na 3 modele. 

1. Pierwszy, który można nazwać „liniowym”, polega na odczytaniu danych wej¬ 
ściowych, dokonaniu pewnych obliczeń, zapisaniu danych wyjściowych i zakoń- 
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czeniu pracy. Stosowany bywa np. w obliczeniowych programach naukowych, 
w prostych programach dydaktycznych czy w skryptach administracyjnych. 

2. Drugi model, który można nazwać „sterowanym zdarzeniami”, polega na ocze¬ 
kiwaniu w pętli na polecenia użytkownika i wykonywaniu tych poleceń. Jest 
charakterystyczny dla programów z interfejsem okienkowym. 

3. Trzeci model jest wykorzystywany w grach. Można go nazwać modelem „czasu 
rzeczywistego”. Polega na wykonywaniu w pętli nieustannych obliczeń polega¬ 
jących na aktualizacji stanu symulacji na podstawie kroku czasowego, a także 
odrysowaniu nowej klatki obrazu na ekranie. W każdej iteracji pętli jest też 
sprawdzane wejście od użytkownika, ale program nie oczekuje na komunikaty 
wejściowe. 


Prezentowany tu szkielet aplikacji może działać w trybie 2 lub 3. Zmiana mo¬ 
delu następuje przez wywołanie funkcji SetLoopMode. Podanie jako parametru false 
powoduje, że program nie będzie wykonywał nieustannie pętli, tylko oczekiwał na wej¬ 
ście od użytkownika, a co za tym idzie nie będzie wykorzystywał całej dostępnej mocy 
obliczeniowej procesora. To dobre rozwiązanie dla programów okienkowych, edytorów 
czy gier turowych. Z drugiej strony, gry i symulacje czasu rzeczywistego bądź jakie¬ 
kolwiek prezentujące animacje muszą działać w domyślnym trybie, w którym pętla nie 
blokuje się czekając na komunikaty od użytkownika. 

Aby utworzyć obiekt odbierający wywołania zwrotne dotyczące zdarzeń inicjalizacji 
i finalizacji całego programu, jak również utraty/odzyskania urządzenia, minimali¬ 
zacji/przywrócenia i deaktywacji/aktywacji jego okna, należy odziedziczyć po klasie 
IFrameObject i zarejestrować obiekt funkcją RegisterFrameObject. Listę metod 
tego interfejsu pokazuje poniższy listing: 

class IFrameObject 

{ 

public: 

v±rtual void OnCreate() ; 

v±rtual void OnDestroyO; 

virtual void OnLostDevice (); 

v±rtual void OnResetDevice (); 

v±rtual void OnRestore () ; 

virtual void OnMinimize(); 

v±rtual void OnActivate (); 

v±rtual void OnDeactivate (); 

v±rtual void OnResume(); 

virtual void OnPause(); 

virtual void OnTimer(uint4 Timerld); 


Analogicznie wygląda odbieranie wywołań zwrotnych z komunikatami od klawia¬ 
tury i myszki. Aby to zrobić, należy odziedziczyć po klasie IlnputOb ject i zarejestro¬ 
wać obiekt funkcją RegisterlnputOb ject. Wspomniany interfejs posiada następu¬ 
jące metody: 
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class IlnputObject 

{ 


public: 

virtual bool OnKeyDown(uint4 Key); 
virtual bool OnKeyUp(uint4 Key); 
virtual bool OnChar(char Ch); 
virtual bool OnMouseMove(const VEC2 &Pos); 
virtual bool OnMouseButton(const VEC2 &Pos, 
MOUSE_ACTION Action) ; 

virtual bool OnMouseWheel(const VEC2 SPos, 


MOUSE_BUTTON Button, 
float Delta); 


Omawiany moduł dostarcza również układu współrzędnych do rysowania wszelkiej 
grafiki 2D. W tym układzie podaje też pozycję kursora myszy. Na definicję tego układu 
współrzędnych składa się określona szerokość, wysokość i wybrany jeden spośród 3 
możliwych trybów. W zależności od niego inne jest mapowanie pikseli na wirtualne 


jednostki, tak jak to pokazuje rys. 2.3 


MC PIXELS 


MC FIXED HEIGHT MC FIXED 


800 x 600 pikseli 
4:3 



800 x 600 jednostek 


640 x 480 pikseli 
4:3 



640 x 480 jednostek 



800 x 600 jednostek 



800 x 600 jednostek 



800 x 600 jednostek 



800 x 600 jednostek 



Rys. 2.3. Rozdzielczość ekranu 2D w wirtualnych jednostkach dla podanych parametrów 

MouseCoordsWidth= 800, MouseCoordsHeight= 600 i różnych tiybów pracy. 


Ponadto, mysz może pracować w „trybie kamery”. Można ten tryb uaktywnić funk¬ 
cją SetMouseMode. Wówczas zwracana jest nie pozycja kursora, ale jego względne 
przesunięcie od położenia poprzedniego. Zostało to zrealizowane poprzez przemiesz¬ 
czanie kursora po każdym ruchu z powrotem na środek ekranu. Dzięki temu myszkę 
w tym trybie można przesuwać w każdą stronę o dowolną odległość bez ograniczenia 
krawędziami ekranu. Taki tryb ma zastosowanie do sterowania kamerą, np. w grach 
FPP (z perspektywy pierwszej osoby). 
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Szkielet dokonuje także pomiaru czasu. Korzysta w tym celu z odpowiednich moż¬ 
liwości biblioteki bazowej. Warstwom wyższym natomiast udostępnia obiekty Timerl 
i Timer2, z których można pobierać czas, jaki minął od uruchomienia programu oraz 
krok czasowy od poprzedniej klatki, wyrażone jako liczby typu float, w sekundach. 
Każdy z tym zegarów można zatrzymywać i wznawiać, posiadają one wewnętrzne licz¬ 
niki zatrzymań. Timer2 jest przeznaczony do sterowania właściwą symulacją, pod¬ 
czas gdy z obiektu Timerl należy korzystać przy animowaniu elementów interfejsu 
użytkownika itp. Dzięki temu rozróżnieniu każdym z tych zegarów można sterować 
osobno, np. zatrzymać symulację, ale nie cały interfejs programu. Kod pomiaru czasu 
dodatkowo wylicza średnią liczbę klatek na sekundę (FPS — ang. Frames Per Second ), 
która jest najczęściej używaną miarą wydajności w grach. Można tą wartość pobrać 
za pomocą funkcji GetFPS. 

Szkielet zajmuje się też wyłapywaniem i obsługą błędów w postaci wyjątków. Musi 
to robić w wielu miejscach swojego kodu, ponieważ wyjątek C++ nie może się dostać 
do kodu WinAPI. Każdy taki błąd jest zapisywany do pliku Errors. log i powoduje 
zakończenie działania programu (jednak nie jego przerwanie, ale normalne zamknięcie 
z wywołaniem zwalniania wszelkich zaalokowanych obiektów). 

Manager zasobów Zasób można zdefiniować jako każdy taki obiekt, którego utwo¬ 
rzenie wraz z zawartymi w nim danymi wymaga czaso- i pracochłonnej operacji, naj¬ 
częściej wczytania pliku z dysku, ewentualnie wygenerowania proceduralnego. Przy¬ 
kładami zasobów w kontekście grafiki 3D są tekstury, siatki trójkątów czy shadery. 
Manager zasobów, jako moduł przechowujący kolekcję zasobów i dający do nich do¬ 
stęp, jest ważną częścią każdego szkieletu i silnika graficznego. Jego implementacja 
wiąże się z podjęciem kilku decyzji projektowych. 

Jedną z takich decyzji jest napisanie osobnych managerów przeznaczonych dla po¬ 
szczególnych rodzajów zasobów — np. tekstur, siatek trójkątów, shaderów itp. bądź 
jeden uogólniony manager wszystkich zasobów. Autor zdecydował się na to drugie 
rozwiązanie. Jego kod znajduje się w plikach Framework\ResMngr . hpp 
i Framework\ResMngr. cpp. Obiekt managera jest ogólnodostępny pod globalnym 
wskaźnikiem g_Manager. Wszelkie typy zasobów są klasami dziedziczącymi 
zIResource. 

Drugą decyzją projektową jest sposób dostępu do zasobów. Istnieje wiele rozwiązań 
tego problemu, a każde ma swoje zalety i wady. Najbardziej intuicyjne jest skojarzenie 
z każdym zasobem nazwy jako łańcucha znaków. Wyszukiwanie zasobów po nazwie 
jest jednak kosztowne obliczeniowo. Dlatego ulepszenie tej metody może polegać na 
zapamiętywaniu jedynie hasha z nazwy. Inny sposób to nadawanie zasobom identy¬ 
fikatorów liczbowych lub uchwytów. Autor niniejszej pracy zdecydował się na nastę¬ 
pujące rozwiązanie: Zasoby są identyfikowane przez nazwy i pamiętane w strukturze 
danych std: :map<string, IResource*>, która pozwala na ich względnie szybkie 
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wyszukiwanie. Ponadto każdy zasób istnieje jako obiekt zawsze, niezależnie od tego 
czyjego dane są wczytane. Dzięki temu wyszukiwanie zasobu po nazwie można prze¬ 
prowadzać tylko raz (podczas tworzenia obiektu który korzysta z zasobu lub podczas 
pierwszego użycia zasobu), a potem już posługiwać się wprost wskaźnikiem do zasobu. 

Ponieważ zasoby mogą być różnych typów i są przechowywane razem, zachodzi 
potrzeba rzutowania w dół obiektów klasy bazowej IResource na klasy pochodne. 
Aby uczynić wyszukiwanie zasobu prostszym i wygodniejszym, rzutowanie to wraz ze 
sprawdzaniem typu za pomocą RTTI jest ukryte w szablonie metody: 
template <typename T> 

T * MustGetResourceEx(const string SName) 

{ 

IResource *R = MustGetResource(Name); 

if (typeid(*R) != typeid(T)) throw Error ( .. .); 

return static_cast<T*>(R); 

} 

Istnieje wiele sposobów na używanie zasobów. Najprostszy polega na wczytaniu 
listy zasobów i danych każdego z tych zasobów podczas uruchamiania programu. 
W programach z dużą liczbą zasobów, takich jak współczesne gry, jest to jednak nie¬ 
możliwe i zasoby trzeba ładować oraz zwalniać w razie potrzeby — podczas specjalnej 
fazy ładowania lub już podczas normalnej pracy programu, np. przy pierwszym uży¬ 
ciu. Opisywany manager zasobów pozwala na takie operacje. Dalesze rozszerzenie 
tych możliwości polegałoby na wczytywaniu zasobów w tle. Jest to potrzebne w pew¬ 
nego typu grach, jednak znacznie komplikuje budowę managera zasobów (konieczne 
jest użycie osobnego wątku i odpowiednia synchronizacja), dlatego opisywany tutaj 
manager nie posiada takiej możliwości. 

Lista zasobów może się znajdować w specjalnym pliku tekstowym. Dzięki temu 
można ją zmieniać bez rekompilacji programu. Format takiego pliku został zbudo¬ 
wany w oparciu o tokenizer (patrz p. El i jest rozszerzalny w taki sposób, że nowe 
typy zasobów mają obowiązek dostarczać metody statycznej parsującej parametry za¬ 
sobu tego typu. Ponadto istnieje możliwość dynamicznego tworzenia i usuwania za¬ 
sobów w czasie pracy programu z poziomu jego kodu, bez użycia opisu tekstowego. 

Każdy zasób (obiekt klasy pochodnej od IResource) ma swój stan oznaczający, 
czy jego dane są wczytane. Jeśli zasób jest wczytany (można to sprawdzić metodą 
IsLoaded), użytkownikowi wolno pobierać te dane metodami charakterystycznymi dla 
zasobu danego rodzaju. Wczytania zasobu można dokonać metodą Load, a zwolnie¬ 
nia jego danych metodą Unload. Zasób nieużywany przez określony czas (domyślnie 
2 minuty) jest automatycznie zwalniany. Istnieje możliwość zablokowania zasobu me¬ 
todą Lock, co daje gwarancję, że pozostanie on wczytany aż do odblokowania metodą 
Unlock. Zasób posiada wewnętrzny licznik zablokowań. 

Te funkcje można wykorzystać na jeden z dwóch typowych sposobów: 

1. Jeśli zasobów jest niewiele i program potrzebuje ich wszystkich do działania, 
może zablokować każdy zasób metodą Lock lub zdefiniować zasoby jako stale 
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zablokowane w ich definicji w pliku tekstowym. Zasoby są ładowane w chwili 
tego wywołania i pozostają załadowane aż do zakończenia programu. 

2. Jeśli zasobów jest dużo, program może wczytywać tylko te potrzebne w danej 
chwili, przed ich użyciem. Musi w tym celu wywoływać metodę Load zasobu 
przed każdym jego użyciem, gdyż pozostanie zasobu w stanie wczytanym po tym 
wywołaniu jest gwarantowane tylko do końca danej klatki. Potem manager może 
zdecydować o zwolnieniu zasobu. 

Zadaniem klasy pochodnej reprezentującej konkretny typ zasobu jest dostarczenie 
implementacji metod abstrakcyjnych: On Load służącej do wczytania zasobu, OnUnload 
służącej do zwolnienia jego danych i opcjonalnie OnEvent, oznaczającej dodatkowe 
zdarzenia. To dodatkowe zdarzenie jest wykorzystane do powiadomienia zasobów 
o utracie i odzyskaniu urządzenia Direct3D, co zmusza do ponownego wczytania za¬ 
sobów Direct3D umieszczonych w puli pamięci DEFAULT. Inne rodzaje zasobów mogą 
to zdarzenie zignorować. 

Pliki Framework\Res_d3d. hpp i Framework\Res_d3d. cpp dostarczają implemen¬ 
tacji klas zasobów związanych z Direct3D. Klasą bazową wszystkich takich zasobów 
jest D3dResource. Tłumaczy ona wywołania związane z zasobami ogólnie — OnLoad, 
OnUnload i OnEvent — na wywołania charakterystyczne dla zasobów Direct3D, któ¬ 
rych zaimplementowanie pozostawia klasom pochodnym: OnDeviceCreate, 
OnDeviceDestroy, OnDeviceRestore, OnDeviceInvalidate. Klasy pochodne do¬ 
starczane przez wspomniane wyżej pliki to: 

• D3dBaseTexture to klasa bazowa dla wszelkiego rodzaju tekstur Direct3D. 

• D3dTexture reprezentuje zwyczajną, dwuwymiarową teksturę. 

• D3dCubeTexture reprezentuje teksturę sześcienną. 

• D3dFont reprezentuje czcionkę ID3DXFont. 

• D3dEffect reprezentuje efekt ID3DXEffect. 

• Font reprezentuje własną implementację czcionki wczytywanej na podstawie 
pliku graficznego z obrazem znaków i dodatkowego pliku tekstowego z opisem, 
tworzonych przez osobne narzędzie — Bitmap Font Generator. 

• D3dTextureSurface reprezentuje teksturę i/lub powierzchnię D3D używaną 
jako cel renderowania. 

• D3dCubeTextureSurface reprezentuje teksturę i/lub powierzchnię sześcienną 
D3D używaną jako cel renderowania. 

• D3dVertexBuf fer reprezentuje bufor wierzchołków D3D. 

• D3dIndexBuffer reprezentuje bufor indeksów D3D. 

• OcclusionQueries reprezentuje kolekcję zapytań zapytań o zasłanianie (ang. 
Occlusion Query) i wirtualizuje ich pulę udostępniając dowolną liczbę „wirtual¬ 
nych” zapytań. 

Inne moduły rozszerzają zbiór klas zasobów o dodatkowe, bardziej rozbudowane 
typy. Opisane są one w następnych podrozdziałach. 


59 



2. Architektura silnika 


Moduł gMesh Moduł, którego kod znajduje się w plikach Framework\QMesh. hpp 
i Framework\QMesh. cpp, definiuje klasę QMesh. Jest ona rodzajem zasobu, który re¬ 
prezentuje model, czyli siatkę trójkątów wraz z dodatkowymi informacjami stanowiącą 
reprezentację kształtu jakiegoś obiektu. Jest to właściwie najważniejszy typ zasobu 
— grafika 3D prawie w całości składa się z takich siatek trójkątów (3). 

Klasa potrafi wczytywać plik w formacie QMSH, zaprojektowanym specjalnie na 
potrzeby niniejszej pracy (patrz rozdz. 3.3) . Pliki tego formatu przygotowywane są na 
podstawie formatu pośredniego QMSH.TMP przez narzędzie konsolowe Tools (patrz 
rozdz. 2.6) . Wewnętrznie do przechowywania wczytanych informacji klasa używa 
bufora wierzchołków i bufora indeksów Direct3D oraz dodatkowych struktur prze¬ 
chowujących odpowiednie metadane. 

Oprócz udostępniania na zewnątrz wczytanych informacji oraz dostępu do bufo¬ 
rów, które potrzebne są podczas renderowania siatki, klasa wspiera także Skinning, 
czyli animację szkieletową z wagami (patrz |3~4) . Model może posiadać zapisany szkie¬ 
let, który składa się z hierarchii kości, a każdy wierzchołek ma wówczas przypisane 
numery co najwyżej dwóch kości które mają na niego wpływ wraz z ich wagami. 

W celu zrealizowania animacji szkieletowej klasa udostępnia metodę 
GetBoneMatrices zwracającą tablicę macierzy poszczególnych kości w określonej po¬ 
zycji. Macierze te można przekazać jako stałe do Vertex Shadera, aby wykonać skin¬ 
ning sprzętowo na GPU. Klasa potrafi jednak liczyć skinning również na CPU i wyko¬ 
nuje go wewnętrznie, kiedy zachodzi potrzeba sprawdzenia kolizji promienia z animo¬ 
waną siatką w danej pozycji (metoda RayCollision_Bones). 

Wyliczone tablice macierzy kości są buforowane wewnętrznie w strukturach typu 
BoneMatrixCacheEntry. Pamiętana jest ograniczonej długości lista ostatnio używa¬ 
nych takich wpisów, a ich wymiana następuje wg polityki LRU (ang. Last Recently 
Used). Ponowne użycie wpisu przesuwa go z powrotem na koniec listy. Dopasowanie 
podanych parametrów określających wybraną pozycję animacji do wpisów przecho¬ 
wujących zapamiętane tablice macierzy kości może się odbywać z pewną tolerancją. 
Jej zwiększanie powoduje, że rzadziej zachodzi potrzeba wyliczania nowej tablicy ma¬ 
cierzy, a co za tym idzie większa jest wydajność pracy silnika. Z drugiej strony jednak 
animacja jest wtedy mniej płynna. 


Moduł Multishader Shader |67| to program wykonywany przez procesor karty gra¬ 
ficznej (GPU), pisany w specjalnym języku (dawniej był to dedykowany assembler, 
obecnie używany jest język wysokiego poziomu podobny do C — Cg, GLSL lub HLSL). 
Nie daje on takich możliwości jak języki programowania CPU (nie posiada zmiennych 
globalnych, wskaźników, klas itp., a warunki, pętle i wywołania zostały wprowadzone 
dopiero w nowych wersjach). Wykonywany jest za to z prędkością nieosiągalną nawet 
na najlepszych dostępnych obecnie procesorach CPU. Vertex Shader wykonuje się dla 
każdego przetwarzanego wierzchołka, a Pixel Shader dla każdego rysowanego piksela 


60 












2. Architektura silnika 


obrazu, w każdej klatce. Użycie shaderów nazywane jest potokiem programowalnym 
(ang. Programmable Pipeline) i zastępuje ustawienia dostępne na starych generacjach 
kart graficznych w ramach tzw. potoku predefiniowanego (ang. Fixed Function Pipe¬ 
line). Dlatego na shadery można patrzeć jak na bardziej elastyczną metodę określania 
sposobu, w jaki karta przetwarza dane, pozwalającą na zapisanie dowolnej formuły 
matematycznej. 

Pisząc zaawansowany silnik graficzny programista napotyka w tym miejscu pewien 
problem. Zadaniem shadera jest dokonanie wszelkich przekształceń jakie mają się od¬ 
bywać na renderowanych wierzchołkach i pikselach — w tym animację szkieletową, 
oświetlenie, cień, teksturowanie itd. Każda z tych czynności może być konfigurowana 
na różne sposoby. Shaderów nie można jednak ze sobą łączyć —jednocześnie uaktyw¬ 
niony może być tylko jeden Vertex Shader i jeden Pixel Shader i musi on wykonywać 
wszystkie wymagane czynności. 

Stąd powstaje potrzeba utworzenia wielu różnych shaderów dostosowanych do po¬ 
szczególnych kombinacji czynności, które mają przeprowadzać (np. oświetlenie świa¬ 
tłem punktowym, brak cienia, materiał nie posiadający odblasku). Duże możliwości 
silnika szybko prowadzą jednak do eksplozji kombinatorycznej tych ustawień czyniąc 
niemożliwym ręczne przygotowanie, a nawet automatyczne wygenerowanie w rozsąd¬ 
nym czasie shaderów dla wszystkich takich kombinacji. Powstało więc kilka metod 
poradzenia sobie z tym problemem 1681 , 

Podejście naiwne zakłada przygotowanie jednego lub kilku shaderów posiadają¬ 
cych pełny zakres możliwości i tak zaprojektowanych, aby niektóre z obliczeń można 
było pomijać podając odpowiednie wartości jako stałe. Na przykład jeśli kolor wyj¬ 
ściowy może być dodatkowo mnożony przez pewien określony kolor stały C, to poda¬ 
nie jako wartość C koloru białego zaowocuje otrzymaniem niezmienionego koloru, tak 
jakby ta funkcja nie była w shaderze aktywna. Nadal jednak dodatkowe mnożenie 
koloru przez stałą byłoby wykonywane spowalniając niepotrzebnie renderowanie. 

Nieco bardziej zaawansowane podejście zakłada użycia dostępnych w nowych wer¬ 
sjach Shader Model instrukcji warunkowych (ang. Branching ). Jako stałe podawać 
można wartości logiczne oznaczające włączanie lub wyłączanie poszczególnych moż¬ 
liwości shadera. Sprawdzanie tych wartości pozwala na warunkowe wyłączanie frag¬ 
mentów kodu shadera. Zdaniem autora nie warto jednak marnować czasu na spraw¬ 
dzanie takiego warunku w kodzie wykonywanym dla każdego wierzchołka czy piksela, 
jeśli cały obiekt może być wyrenderowany z użyciem shadera w wersji całkowicie po¬ 
zbawionej danego fragmentu kodu. 

Najbardziej zaawansowane podejście zakłada kompilowanie na żądanie (przy pierw¬ 
szym użyciu) wersji shadera posiadającej tylko potrzebne funkcje. W celu budowania 
kodu źródłowego takiego shadera zastosować można jeden z dwóch modeli 1681 : 

• Model addytywny 1691 polega na składaniu kodu shadera z pewnych fragmen¬ 
tów, przy czym wyjścia jednych są łączone z wejściami innych. Wymaga to opra- 
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cowania sposobu opisywania tych fragmentów oraz ich łączenia. Może się to 
odbywać w specjalnym tekstowym formacie pliku bądź w sposób graficzny — 
za pomocą spotykanego w najbardziej zaawansowanych silnikach edytora ma¬ 
teriałów, w którym użytkownik może łączyć prostokątne bloczki reprezentujące 
fragmenty shadera za pomocą myszki. 

• Model subtraktywny polega na przygotowaniu jednego długiego kodu shadera 
posiadającego wszystkie przewidywane możliwości i wplecenia do niego dyrek¬ 
tyw preprocesora kompilacji warunkowej takich jak #ifdef. Język shaderów 
wysokiego poziomu HLSL posiada bowiem preprocesor bardzo podobny do tego 
w C/C++. Dzięki nim kompilator dla konkretnego shadera może wybrać tylko 
pewne fragmenty kodu poprzez zdefiniowanie używanych do kompilacji makr 
preprocesora. 

Autor wybrał podejście subtraktywne. Podejście to czyni shader prostszym do na¬ 
pisania, ale równocześnie dużo trudniejszym do konserwacji. Kod głównego shadera 
w opisanym w tej pracy silniku liczy 907 wierszy. Shader ten jest opisany w rozdz. 

Moduł Multishader, którego kod zgromadzony jest w plikach 
Framework\Mult i shader. hpp i Framework\Mult i shader . cpp, definiuje klasę 
Multishader. Jest to rodzaj zasobu, który reprezentuje zbiór shaderów kompilowa¬ 
nych na żądanie z podanymi ustawieniami, powstających ze wspólnego kodu źródło¬ 
wego w języku HLSL (wczytywanego z pliku FX). Owe ustawienia to tablica wartości 
całkowitoliczbowych ustawianych jako makra preprocesora podczas kompilacji sha¬ 
dera. Na podstawie tych wartości, składanych w sposób bitowy, powstaje tzw. hash 
— pojedyncza liczba 32-bitowa, która jednoznacznie identyfikuje dany shader. Jest 
ona używana do sprawdzenia, czy shader o podanych ustawieniach jest już wczytany 
do pamięci. Jeśli nie jest, klasa sprawdza, czy był wcześniej kompilowany i zapisany 
w wynikowej postaci binarnej do pliku w katalogu tymczasowym. Jeśli tak, wczytuje 
ten plik. Jeśli nie znajdzie takiego pliku, dopiero wówczas kompiluje shader ze źródła. 

Moduł Gfx2D Kod znajdujący się w plikach Framework\Gf x2D . hpp 
i Framework\Gfx2D. cpp, zgromadzony w przestrzeni nazw gfx2d, to moduł służący 
do rysowania grafiki dwuwymiarowej za pomocą Direct3D. Możliwości takie są po¬ 
trzebne w każdej aplikacji graficznej. W przypadku gier dwuwymiarowych za pomocą 
tego modułu można rysować całą grafikę. Jednak nawet w przypadku gier i pro¬ 
gramów trójwymiarowych, zawsze zachodzi potrzeba rysowania pewnych elementów 
płaskich, jak choćby kontrolek interfejsu użytkownika. 

Biblioteki graficzne mogą być zaprojektowane na dwa sposoby, przy czym przed¬ 
stawiony tu podział dotyczy równie dobrze grafiki 2D, jak i 3D. Pierwszy model to do¬ 
starczenie funkcji rysujących, które za każdym razem muszą zostać wywołane w celu 
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odrysowania poszczególnych elementów graficznych na ekranie. Takie API posiada 
np. Windows GDI. jak również Direct3D. Drugi model polega na przechowywaniu 
przez bibliotekę kolekcji obiektów graficznych, na których użytkownik może manipu¬ 
lować dodając je i usuwając, zmieniając ich pozycje, wymiary, kolor i inne parametry. 
Biblioteka sama zajmuje się każdorazowym odrysowaniem wszystkich pamiętanych 
obiektów. 

Opisywany tu moduł grafiki 2D używa pierwszego modelu. Udostępnia on zmienną 
globalną g_Canvas typu Canvas, która posiada metody służące do rysowania ele¬ 
mentów graficznych 2D: prostokątów wypełnionych jednolitym kolorem, prostokątów 
wypełnionych teksturą (spritów — p. niżej) oraz tekstu. Służą do tego metody odpo¬ 
wiednio DrawRect oraz DrawText_. Ponadto między wywołaniami rysującymi można 
przestawiać parametry rysowania za pomocą metod: SetColor, która ustawia bieżący 
kolor, SetSprite, która ustawia bieżący sprite oraz SetFont, która ustawia bieżącą 
czcionkę. 

Oprócz parametrów rysowania ustawianych w normalny sposób (np. użytkownik 
ustawia kolor biały, rysuje białe prostokąty, zmienia kolor na czerwony, rysuje czer¬ 
wone prostokąty), klasa posiada parametry odkładane na stos. Są to: PushAlpha 
i PopAlpha ustalające stopień półprzezroczystości, PushTranslation 
i PopTranslation ustalające przesunięcie oraz PushClipRect i PopClipRect ustala¬ 
jące prostokąt obcinania. Rysowanie prostokątów, jak również pojedynczych znaków 
tekstu, odbywa się poprzez rysowanie tzw. quadów, czyli par trójkątów (patrz rys. 
2.4) . Klasa nie wspiera przekształceń takich jak obroty, co było świadomą decyzją 
projektową, ponieważ ich wprowadzenie znacznie skomplikowałoby algorytm przyci¬ 
nania i tym samym uczyniłoby go mniej wydajnym. 



Rys. 2.4. Prostokąty 2D rysowane z użyciem Direct3D powstają z dwóch trójkątów 
utworzonych za pomocą 4 wierzchołków i 6 indeksów. 

Współczesne karty graficzne są zbudowane w taki sposób, że zdolne są do rysowa¬ 
nia ogromnej ilości geometrii, ale w celu uzyskania ich pełnej wydajności potrzebują 
dostawać tą geometrię w dużych porcjach (ang. Batch). Tymczasem rysowanie z uży¬ 
ciem klasy Canvas odbywa się za pomocą pojedynczych prostokątów. Aby przyspie¬ 
szyć ten proces, klasa wewnętrznie buforuje wywołania rysujące starając się zbierać 
zakolejkowane w pamięci tak dużo wywołań rysowania prostokątów, jak to tylko moż- 
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llwe i wysyłać je do karty w graficznej w jednej porcji. Oczywiście rysowanie wielu 
prostokątów na raz musi się odbywać z użyciem tych samym ustawień (jak tekstura, 
shader itd.). Dlatego każda zmiana sprita powoduje opróżnienie kolejki. Toteż uzy¬ 
skiwana wydajność rysowania zależy w dużej mierze od sposobu, w jaki programista 
używa tego modułu. Na przykład jeśli do narysowania jest grupa przycisków inter¬ 
fejsu użytkownika i są one rysowane po kolei, gdzie na przemian następują wywołania 
rysowania tła przycisku i umieszczonego na nim tekstu, wtedy każde takie wywołanie 
zmusza klasę Canvas do opróżnienia kolejki. Jeśliby natomiast najpierw narysowane 
zostały tła wszystkich przycisków, a następnie teksty wszystkich przycisków, klasa 
może lepiej zoptymalizować te wywołania. 

Częstą praktyką w grafice dwuwymiarowej jest umieszczanie na jednej teksturze 
wielu różnych elementów, tak jak to pokazuje rys. 2.5[ Zachodzi potrzeba wyznacze¬ 
nia prostokątnych obszarów na tej teksturze zawierających poszczególne elementy. 
W tym celu moduł wprowadza pojęcie sprite (czyt. „sprajt”), któremu w kodzie odpo¬ 
wiada klasa Sprite. Zawiera ona odniesienie do zasobu tekstury, efektu używanego 
do jej rysowania oraz dane na temat tych prostokątów. Sama nie jest zasobem, po¬ 
nieważ zasoby nie mogą być od siebie zależne. Zamiast tego moduł grafiki 2D prze¬ 
chowuje kolekcję spritów w obiekcie globalnym g_SpriteRepository dając do nich 
dostęp poprzez nazwy. Definicje spritów można wczytywać z pliku tekstowego w spe¬ 
cjalnym formacie bądź tworzyć z poziomu kodu. 



Rys. 2.5. Tekstura z elementami grafiki interfejsu użytkownika używana w przykładowym 

kodzie silnika dołączonym do pracy. 


Metoda Set Sprite klasy Canvas ustawia aktywny sprite używany do rysowania 
prostokątów. Podczas rysowania konkretnego prostokąta metodą DrawRect podać 
należy numer elementu, który ma zostać wybrany do narysowania z aktywnego sprita. 
Numer ten może być jednego z trzech rodzajów. Stała INDEX_ALL to specjalna wartość 
oznaczająca cały obszar tekstury używanej przez sprite. Element prosty, używany po¬ 
przez podanie po prostu wartości jego indeksu, oznacza prostokątny obszar tekstury 
wyznaczony w definicji sprita na jeden z dwóch sposobów — jako macierz lub jako 
prostokąty o dowolnie określonych współrzędnych. Elementy tekstury pokazanej na 
rys. 2.6| mogą być wyznaczone za pomocą macierzy (której siatka jest zaznaczona 
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czerwonymi liniami w|2.6|a) za pomocą poniższej definicji: 
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a) b) 


Rys. 2.6. Sposoby wyznaczania elementów tekstury typu prostego w definicji sprite’a a) za 

pomocą macierzy, b) za pomocą prostokątów. 


matrix { 

2 // Liczba kolumn 

48 48 // Szerokość i wysokość elementu 

12 0 // Odstęp i pozycja początkowa pozioma 

12 0 // Odstęp i pozycja początkowa pionowa 

} 

bądź za pomocą prostokątów (które zaznaczone są na czerwono na rysunku |2.6| b) za 
pomocą poniższej definicji: 

rects { 

0 { left= 0 top= 0 width=48 height=48 } 

1 { left=60 top= 0 width=48 height=48 } 

2 { left= 0 top=60 width=48 height=48 } 

3 { left=60 top=60 width=48 height=48 } 

} 


Elementów graficznych zdolnych do rozszerzania się, takich jak okna czy przyciski, 
nie sposób jednak rysować estetycznie poprzez rozciąganie na ich powierzchni poje¬ 
dynczego obrazu przedstawiającego tło takiego okna czy przycisku, co widać na rys. 


2.7 a. Trzeba składać taki obraz z kilku połączonych elementów przedstawiających 


osobno rogi, osobno krawędzie i osobno środek wypełniający prostokąt, przy czym 
obraz przedstawiający krawędzie i środek może być, zależnie od konkretnego zastoso¬ 
wania, rozciągnięty lub wielokrotnie powtórzony. Dla uproszczenia rysowania takich 
konstrukcji moduł wspiera dodatkowo tzw. elementy złożone. Ich definicja odwo¬ 
łuje się do elementów prostych zdefiniowanych na jeden z opisanych wyżej sposobów 
określając osobno, które proste elementy mają posłużyć do rysowania rogów, które 
do rysowania krawędzi i który do rysowania wypełnienia. Dodatkowo elementy te 
mogą być obracane i odbijane, aby jeden element mógł posłużyć np. do narysowania 
wszystkich czterech rogów przycisku. Numer elementu złożonego podaje się do me¬ 
tody DrawRect poprzez użycie funkcji ComplexElement. Efekt narysowania przycisku 
zdefiniowanego jako element złożony przedstawia rys. |2.7| b). 

Osobnym zagadnieniem jest funkcjonalność rysowania tekstu. Tekst renderowany 
z użyciem Direct3D musi powstawać, podobnie jak cała grafika, z oteksturowanych 
trójkątów. Dlatego każdy znak jest renderowany jako quad złożony z dwóch takich 
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a) b) 

Rys. 2.7. Rysowanie przycisku jako przykład elementu złożonego zbudowanego z elementów 
prostych wyznaczających osobno jego krawędzie, rogi i środek. 


trójkątów. Tekstura przedstawiająca znaki jest przygotowana przez zewnętrzny pro¬ 
gram — Bitmap Font Generator (patrz rys. 2.8) . Osobny plik tekstowy w specjalnym 
formacie, wyznaczający obszary zajmowane przez poszczególne znaki, jest również 
generowany przez ten program. Na jego podstawie klasa Font zawarta w module 
Res_d3d potrafi wyznaczać wymiary poszczególnych znaków, a dzięki nim szerokość 
całego tekstu, jak również automatycznie dzielić tekst na wiersze na granicy słowa 
i dodawać dodatkowe formatowania takie jak podkreślenia i przekreślenia. 
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Rys. 2.8. Tekstura ze znakami czcionki Arial Bold jako przykładowy efekt działania 

programu Bitmap Font Generator. 


Moduł GUI GUI (ang. Graphical User Interface — graficzny interfejs użytkownika) 
oznacza zwykle zbiór okien i różnych kontrolek (takich jak przycisk, lista, pole edy¬ 
cyjne), którymi użytkownik może wygodnie manipulować za pomocą klawiatury i my¬ 
szki. Nie każdy program czy gra potrzebuje zaawansowanego interfejsu użytkownika. 
Są jednak takie zastosowania (np. gry MMORPG), w których rozbudowane GUI jest 
konieczne. Równocześnie pisząc aplikację wykorzystującą do renderowania grafiki 
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Direct3D nie sposób wykorzystać standardowych kontrolek interfejsu użytkownika 
dostarczanych przez system operacyjny. Dlatego konieczne jest napisanie własnego 
systemu GUI. 

System taki jest częścią kodu tej pracy zgromadzoną w plikach Framework\GUI. hpp 
i Framework\GUI. cpp. Jego elementy znajdują się w przestrzeni nazw gui. Podstawo¬ 
wym obiektem jest dostępny jako zmienna globalna g_GuiManager. Przechowuje on 
las kontrolek — trzy osobne drzewa zgrupowane na trzech warstwach (LAYER_NORMAL 
przeznaczona dla zwykłych okien, LAYER_STAYONTOP przeznaczona dla okien zawsze 
na wierzchu i LAYER_VOLATILE przeznaczona dla tymczasowych kontrolek takich 
jak menu albo listy rozwijalne). Każda kontrolka jest obiektem klasy dziedziczącej 
z Control. Obiekty klas dziedziczących z CompositeControl mogą posiadać swoje 
podkontrolki tworząc drzewo. Jest to wzorzec projektowy nazywany kompozytem (ang. 
Composite). 

Oczywiste jest, że klasa kontrolki takiej jak przycisk jest jedna i jej kod nie jest od¬ 
powiedzialny za realizowanie każdej funkcji, którą ma wywoływać dany przycisk (np. 
„OK” czy ,Anuluj” w oknie dialogowym). Zadaniem kontrolki przycisku jest jedynie 
wysłać komunikat o kliknięciu do pewnego ustalonego odbiorcy. Komunikaty takie 
najwygodniej jest realizować za pomocą tzw. wywołań zwrotnych (ang. Callback), 
nazywanych też delegatami (ang. Delegate), zdarzeniami (ang. Event) czy sygnałami 
i slotami (ang. Signals, Slots). W środowisku strukturalnym mogłyby do tego posłużyć 
zwykłe wskaźniki na funkcje. Przy programowaniu obiektowym w C++ powstaje jed¬ 
nak problem, bo język ten (w przeciwieństwie do innych języków programowania, jak 
D, Delphi, C#) nie posiada mechanizmu wskaźników na metody w takiej postaci jak 
potrzebne tutaj. Dlatego do zrealizowania zdarzeń wysyłanych przez kontrolki użyta 
została zewnętrzna biblioteka FastDelegate. 

Poniższy listing prezentuje metody wirtualne definiowane przez klasę bazową 
Control. 


virtual void OnDrawfconst VEC2 STranslation); 

virtual bool OnHitTest(const VEC2 &Pos); 

virtual void GetDefaultSize(VEC2 *Out); 

virtual void OnEnableO; 

virtual void OnDisableO; 

virtual void OnShow(); 

virtual void OnHideO; 

virtual void OnFocusEnter (); 

virtual void OnFocusLeave(); 

virtual void OnMouseEnter(); 

virtual void OnMouseLeave(); 

virtual void OnRectChange(); 

virtual void OnMouseMove(const VEC2 &Pos); 

virtual void OnMouseButton(const VEC2 &Pos, 

frame::MOUSE_BUTTON Button, framę::MOUSE_ACTION Action) 
virtual void OnMouseWheel(const VEC2 &Pos, float Delta); 
virtual void OnDragEnter(Control *DragControl, 
DRAG_DATA_SHARED_PTR a_DragData); 
virtual void OnDragLeave(Control *DragControl, 
DRAG_DATA_SHARED_PTR a_DragData); 
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virtual void OnDragOver(const VEC2 SPos, Control *DragControl, 
DRAG_DATA_SHARED_PTR a_DragData); 
virtual void OnDragDrop(const VEC2 SPos, Control *DragControl, 
DRAG_DATA_SHARED_PTR a_DragData); 
virtual void OnDragCancel(const VEC2 SPos, Control *DragControl, 
DRAG_DATA_SHARED_PTR a_DragData); 
virtual void OnDragFinished(bool Success, Control *DropControl, 
DRAG_DATA_SHARED_PTR a_DragData); 
virtual bool OnKeyDown (uint4 Key); 
virtual bool OnKeyUp (uint4 Key); 
virtual bool OnChar(char Ch); 

Kontrolka może być widzialna (ang. Visible) lub niewidzialna. Stan widzialności 
przechodzi też na podkontrolki. Dzięki temu można ukrywać całe okna. Kontrolka 
może być aktywna (ang. Enabled ) lub nieaktywna (ang. Disabled). Stan aktywności 
również przechodzi na podkontrolki. Kontrolka niewidoczna lub nieaktywna nie może 
otrzymywać skupienia, a tym samym zdarzeń od klawiatury ani też od myszy. 

Istnieje możliwość definiowania kontrolek o nieregularnych kształtach (np. okrą¬ 
głym). Wymiary takiej kontrolki muszą być wówczas ustawione na jej prostokąt ota¬ 
czający, a sprawdzanie czy dane miejsce znajduje się wewnątrz kontrolki realizowane 
jest przez metodę wirtualną OnHitTest. 

Zdarzenia, jakie kontrolka dostaje od myszy obejmują wciśnięcie i zwolnienie przy¬ 
cisku (OnMouseButton), przesunięcie kursora (OnMouseMove) oraz obrócenie rolki 
(OnMouseWheel). Zdarzenia te kontrolka otrzymuje tylko jeśli kursor znajduje się nad 
jej obszarem lub jeśli jest ona w stanie przechwytywania myszy (ang. Mouse Capture). 
Stan przechwytywania włącza się, kiedy następuje wciśnięcie przycisku myszy nad 
obszarem kontrolki i trwa aż do zwolnienia tego przycisku. Oprócz tego kontrolka jest 
informowana o wejściu i wyjściu kursora myszy nad jej obszar wywołaniami metod 
odpowiednio OnMouseEnter i OnMouseLeave. 

Dodatkowo obsługiwany jest mechanizm Drag&Drop — „Przeciągnij i upuść”, po¬ 
zwalający na przeciąganie wirtualnych obiektów między kontrolkami za pomocą kur¬ 
sora myszy. Uczestniczy w tym procesie wiele różnych metod kontrolki, a przekazanie 
dowolnych danych między kontrolką źródłową a docelową odbywa się poprzez inteli¬ 
gentny wskaźnik zdefiniowany jako typ DRAG_DATA_SHARED_PTR. 

Oprócz zdarzeń od myszy, system GUI obsługuje również wejście z klawiatury. W 
każdej chwili tylko jedna kontrolka ma tzw. skupienie (ang. Focus) i właśnie ona 
otrzymuje zdarzenia o naciśnięciach klawiszy. O otrzymaniu lub utracie skupienia 
informują kontrolkę metody OnFocusEnter i OnFocusLeave. Zdarzenia od klawia¬ 
tury to OnKeyDown (oznacza wciśnięcie przycisku lub okresowe powtórzenie), OnKeyUp 
(oznacza zwolnienie przycisku) oraz OnChar. Ta ostatnia metoda, zamiast wirtual¬ 
nego kodu klawisza, podaje wprowadzony znak. Jest to o tyle ważne, że klawisz nie 
jest jednoznaczny ze znakiem który wprowadza jego naciśnięcie. Dzięki otrzymywa¬ 
niu osobnego zdarzenia odpowiedzialnego za wprowadzanie znaków kontrolki takie 
jak pole edycyjne nie muszą we własnym zakresie analizować czy np. wciśnięcie przy¬ 
cisku A oznacza wprowadzenie znaku a, A czy może ą na podstawie stanu klawiszy 
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Shift, Alt i CapsLock. Zajmuje się tym sam system operacyjny uwzględniając bie¬ 
żące ustawienia językowe i układ klawiatury. 

System GUI obsługuje też kursor. Rysowanie kursora należy do użytkownika, 
moduł definiuje jedynie pustą klasę bazową Cursor. To zapewnia maksymalną ela¬ 
styczność. Każda kontrolka może mieć przypisany swój aktualny kursor, a system 
GUI udostępnia do odczytania w każdej chwili informację mówiącą, jaki kursor i w ja¬ 
kiej pozycji powinien być widoczny na ekranie. W przypadku kiedy trwa przeciąganie 
Draw&Drop, kursorem jest obiekt przeciągany, jako że klasa DragData jest pochodna 
od Cursor. Dzięki temu zamiast kursora w takiej sytuacji pokazywany może być 
przeciągany obiekt, co bywa przydatne np. kiedy w grze RPG użytkownik przekłada 
przedmioty w oknie ekwipunku. 

Kolejna możliwość systemu GUI to wyświetlanie dymków z podpowiedzią (ang. 
Hint). Działają podobnie do kursorów. Ich rysowanie również leży w gestii użyt¬ 
kownika, a moduł definiuje jedynie pustą klasę bazową Hint oraz PopupHint. Każda 
kontrolka może mieć przypisaną do siebie podpowiedź. Istnieje możliwość odczyta¬ 
nia w każdej chwili z systemu GUI, jaka podpowiedź i w jakim miejscu powinna być 
aktualnie pokazywana. Ponadto użycie klasy PopupHint pozwala na automatyczne 
obsługiwanie podpowiedzi „wyskakujących” w miejscu kursora po określonym czasie 
od jego zatrzymania nad obszarem danej kontrolki. 

Poważnym problemem, jaki pojawił się podczas implementacji systemu GUI, było 
usuwanie kontrolek. Łatwo mogłoby dojść do sytuacji pokazanej na rys. |2.9 Jeśli 
na przykład użytkownik kliknął myszką na przycisk, szkielet przesyła odpowiednie 
zdarzenie do systemu GUI. który przesyła je z kolei do odpowiedniej kontrolki, nad 
którą znajduje się kursor myszy. Ta kontrolka, jako przycisk, generuje w reakcji na 
kliknięcie wywołanie zdarzenia o wciśnięciu przycisku. Jeśli to jest przycisk „OK” po¬ 
twierdzający okno dialogowe, jego kliknięcie powinno spowodować zamknięcie i zwol¬ 
nienie z pamięci całego okna, w tym także tego przycisku. Jednak kod klienta, który 
spróbowałby to zrobić, usunąłby obiekt będąc tak naprawdę w czasie wykonywania 
jednej z jego metod! Samo w sobie nie jest to błędem, ale jeśli jakiś kod w systemie 
GUI próbowałby dalej korzystać z tego obiektu, nieuchronnie doprowadziłoby to do 
zamknięcia całego programu z błędem ochrony pamięci. Dlatego autor zdecydował się 
na opóźnianie wywołań wszelkich zdarzeń wysyłanych przez system GUI do kontrolek 
(tych z listingu powyżej) poprzez umieszczanie ich w specjalnej kolejce. 

Pliki Framework\GUI_Controls . hpp i Framework\GUI_Controls . cpp dostarczają 
standardowej implementacji pewnego zbioru kontrolek. 


• Label reprezentuje statyczny tekst, który służy tylko celom informacyjnym i nie 
odbiera żadnych zdarzeń od użytkownika. 

• Button reprezentuje przycisk, który można „wciskać” za pomocą kliknięcia 
myszką, z pokazywanym na nim tekstem. 

• SpriteButton reprezentuje przycisk z pokazywanym na nim obrazem. 
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Rys. 2.9. Diagram sekwencji obrazujący problem z usuwaniem kontrolki w czasie 
wykonywania otrzymanego od niej zdarzenia. 

• CheckBox reprezentuje pole opisane tekstem, które użytkownik może przesta¬ 
wiać w stan „zaznaczony”/„odznaczony” poprzez klikanie myszką. 

• RadioButton reprezentuje pole posiadające opis tekstowy, które można zazna¬ 
czać, przy czym na raz może być zaznaczona tylko jedna kontrolka w grupie. 

• TrackBar reprezentuje pasek, który można przesuwać zmieniając pewną wartość 
liczbową. 

• ScrollBar reprezentuje pasek przewijania, przydatny na przykład do przewija¬ 
nia długich dokumentów tekstowych. 

• GroupBox to kontrolka prezentująca prostokąt grupujący w sposób wizualny, jak 
i logiczny kontrolki umieszczone w jego wnętrzu. 

• TabControl to zestaw zakładek, między którymi można się przełączać. Każda 
z nich wyświetla kartę, na której mogą być umieszczone inne kontrolki. 

• Menu reprezentuje wyskakujące menu z poleceniami do wyboru. 

• Window reprezentuje okno, które posiada pasek tytułowy, które można przesu¬ 
wać i rozszerzać i które posiada w swoim wnętrzu inne kontrolki. 

• Edit to najbardziej skomplikowana ze wszystkich kontrolek (jej kod źródłowy ma 
ponad 1200 linii). Zapewnia możliwość wprowadzania jednowierszowego tekstu 
wraz z przewijaniem długiego tekstu, pozycjonowaniem kursora, zaznaczaniem, 
obsługą schowka itp. funkcjami, które posiada również standardowa kontrolka 
systemowa tego typu. 

• List to ogólna kontrolka prezentująca listę pozycji, zaprojektowana wg wzorca 
MVC (ang. Model View Controller — Model-Widok-Kontroler). Ta klasa bazowa 
stanowi kontroler (sposób obsługi komunikatów wejściowych), widok (sposób ry¬ 
sowania) realizuje jej klasa pochodna, a model (przechowywanie danych) reali¬ 
zuje osobny obiekt klasy pochodnej od IListModel. 

• TextComboBox to lista rozwijalna, z której można wybrać tekst lub wpisać do¬ 
wolny inny w dostępnym polu tekstowym. 
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• ListComboBox to lista rozwijalna bez możliwości wpisania własnego tekstu. 


Ponadto osobny moduł, który stanowią pliki 

Framework\GUI_PropertyGridWindow.hpp 

i Framework\GUI_PropertyGridWindow. cpp, dostarcza rozbudowanej kontrolki 
PropertyGridWindow. Jest to okno prezentujące listę wartości różnego typu, przy 
czym do zmiany każdej z nich tworzone są osobne kontrolki zależnie od jej typu — np. 
do edycji wektora 3D powstają trzy pola edycyjne, do edycji koloru wraz z kanałem 
Alfa cztery suwaki i podgląd, do edycji łańcucha znaków powstaje pole tekstowe itd. 

Zaimplementowany tu zestaw kontrolek nie wyczerpuje oczywiście wszystkich moż¬ 
liwości. Zależnie od konkretnych potrzeb może się okazać aż nadto rozbudowany lub 
też zbyt ubogi. Nie ma w nim np. drzewa ( TreeView ), pola do wprowadzania tekstu 
wielowierszowego (Memo) i innych kontrolek trudnych w implementacji. Zrzut ekranu 
z przykładowego programu demonstrującego możliwości opisanego tu systemu GUI 
prezentuje rys. |2TT0j 
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Rys. 2.10. GUI TechDemo — program demonstracyjny prezentujący możliwości systemu 

GUI (graficznego interfejsu użytkownika). 


2.5. Architektura silnika 


Właściwy kod silnika graficznego znajduje się w katalogu Engine. Do realizowania 
swoich funkcji wymaga jednak warstw niższych, dlatego nie sposób rozpatrywać go 
w oderwaniu od omówionych wcześniej modułów takich jak moduł matematyczny 
(patrz rozdz. 2.3) czy manager zasobów (patrz rozdz. 2.4) . 

Jak już zostało napisane we wstępie, silnik stanowi warstwę pośrednią między pro¬ 
gramem, a biblioteką graficzną taką jak DirectX. Ilustruje to rysunek |2.11[ Biblioteka 
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graficzna udostępnia tylko funkcjonalność karty graficznej, a więc umożliwia rende- 
rowanie trójkątów oraz posługiwanie się zasobami niskiego poziomu takimi, jak bufor 
wierzchołków, bufor indeksów, tekstura czy shader. Silnik ukrywa takie szczegóły 
implementacyjne udostępniając obiekty reprezentujące pojęcia bardziej abstrakcyjne 
jak scena, kamera, światło czy model. 



Rys. 2.11. Miejsce silnika w strukturze współczesnej gry komputerowej. 


Ważnym założeniem przy projektowaniu tego silnika było, aby stanowił on za¬ 
mkniętą bibliotekę enkapsulującą w swoim wnętrzu wszelkie szczegóły implementa¬ 
cyjne. Stoi to w kontraście do niektórych innych dostępnych w Internecie silników 
graficznych, które stanowią jakby tylko platformę oczekującą na rozszerzenie i zaim¬ 
plementowanie różnych szczegółów. Autorowi zależało, aby tego silnika można było 
używać nie zajmując się problemami niskopoziomowymi i aby przez to był łatwy w uży¬ 
ciu. Na przykład użytkownik powinien operować jedynie na parametrach materiału 
bez wglądu w ich implementację, np. w kod shaderów. Zostało to osiągnięte kosztem 
możliwości łatwej rozbudowy, np. o nowe efekty materiałowe czy efekty postproces- 
singu. 

Moduł kamery Kamera to pojęcie oznaczające „punkt widzenia”, z którego rendero- 
wana jest trójwymiarowa scena. Na niskim poziomie sprowadza się do dwóch macie¬ 
rzy: 

1. Macierz widoku (ang. View Matrix) dokonuje przekształcenia ze współrzędnych 
świata do współrzędnych kamery. Reprezentuje pozycję kamery w przestrzeni 
oraz jej orientację, w tym głównie kierunek patrzenia. 

2. Macierz rzutowania (ang. Projection Matrix) dokonuje rzutowania perspekty¬ 
wicznego. Reprezentuje odległość bliskiej i dalekiej płaszczyzny obcinania (Z- 
Near, Z-Far), kąt widzenia (FOV — ang. Field o/View) oraz stosunek szerokości 
do wysokości (ang. Aspect Ratio). 

Ponadto obszar widoczny w kamerze można przedstawić jako frustum — ścięty 
ostrosłup o podstawie prostokąta (patrz rys. |2. 12) . Pobieranie jego kształtu jest po¬ 
trzebne do testowania, czy obiekt jest widoczny z punktu widzenia danej kamery (ang. 
Frustum Culling). Jeśli nie jest, można pominąć jego rysowanie. 

Zaprojektowanie funkcjonalnej, elastycznej i wygodnej klasy kamery nie jest pro¬ 
ste, jeśli wziąć pod uwagę, że musi ona działać jak najwydajniej. Dlatego jej implemen¬ 
tacja stosuje kilka nietypowych rozwiązań. Ogólna struktura klasy kamery pokazana 
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Rys. 2.12. Pojęcie kamery jako układu współrzędnych i frustuma. 


( -\ 

Camera 

C -\ 

ParamsCamera 

— 

MatrixCamera 


Rys. 2.13. Struktura kamery. 

jest na rysunku |2.13[ Każda klasa wewnętrzna może istnieć samodzielnie, natomiast 
każda zewnętrzna zawiera w sobie też pokazane klasy wewnętrzne. 

Klasa MatrixCamera reprezentuje tą najbardziej wewnętrzną, docelową część pa¬ 
rametrów kamery. Obiekt tej klasy powstaje przez podanie macierzy widoku View 
i rzutowania Pro j. Przechowuje oraz udostępnia do odczytu te macierze, jak również 
ich wersję połączoną ViewProj i ich odwrotności (Viewlnv, ProjInv, ViewPro jInv). 
Ponadto generuje na ich podstawie frustum opisany przez płaszczyzny (typu 
FRUSTUM_PLANES), opisany przez wierzchołki (typu FRUSTUM_POINTS) oraz AABB tego 
frustuma (typu box). 

Klasa ParamsCamera reprezentuje kamerę sterowaną parametrami, na podstawie 
których wyznaczane są te dwie macierze. Obiekt tej klasy powstaje przez podanie: po¬ 
zycji kamery EyePos, kierunku patrzenia ForwardDir, kierunku wskazującego górę 
UpDir, kąta widzenia pionowego FovY, stosunku szerokości do wysokości Aspect oraz 
odległości bliskiej i dalekiej płaszczyzny przycinania ZNear, ZFar. Oprócz przechowy¬ 
wania i udostępniania tych parametrów posiada pole typu MatrixCamera, do którego 
wpisuje macierze wygenerowane na ich podstawie. Potrafi także wyliczyć dodatkowe 
wektory potrzebne do niektórych operacji — wektor w prawo RightDir i „prawdziwy” 
wektor do góry Real UpDir, które razem z wektorem kierunku patrzenia tworzą bazę 
ortonormalną. 

Klasa Camera reprezentuje kamerę sterowaną takimi parametrami, jakimi zwykle 
posługuje się użytkownik silnika 3D. Oprócz parametrów rzutowania (takich samych 
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jak w klasie powyżej) są to: pozycja kamery oraz jej orientacja. Orientacja może być 
opisana na wybrany spośród dwóch sposobów: za pomocą dwóch z kątów Eulera 
(AngleY, AngleX) lub za pomocą kwaterniona (Orientation). Ta pierwsza możliwość 
używana jest, kiedy użytkownik programu ma możliwość bezpośredniego sterowania 
kamerą za pomocą myszki. Ta druga natomiast przydatna jest do automatycznego 
sterowania kamerą, np. podczas scenek filmowych (ang. Cutscene), kiedy kamera 
płynnie przesuwa się i obraca za pomocą interpolacji po z góry ustalonej krzywej. 
Ponadto punkt widzenia kamery może być odsunięty względem jej wirtualnej „pozycji” 
o podaną odległość CameraDist, co pozwala łatwo zrealizować perspektywę TPP (ang. 
Third Person Perspective — perspektywa trzeciej osoby). Ustawienie tej wartości na 
0 daje kamerę FPP (ang. First Person Perspectwe — perspektywa pierwszej osoby). 

Klasa ta przechowuje w sobie obiekt typu ParamsCamera, wpisuje do niego para¬ 
metry wyliczone na podstawie swoich danych i daje dostęp do tego obiektu. Dodat¬ 
kową funkcją tej klasy jest umiejętność wyliczenia parametrów promienia (półprostej) 
we współrzędnych świata na podstawie podanej pozycji (. x,y ), na przykład miejsca 
kliknięcia myszką na ekranie. 

Parametry, które każda z tych klas potrafi wyliczać, są wyliczane przy pierwszym 
ich użyciu. To tzw. wartościowanie leniwe (ang. Łazy Eoaluation). Dzięki niemu 
przykładowo niezależnie od tego, czy nastąpi najpierw 10 razy zmiana parametrów 
kamery i potem 1 raz odczytanie jej macierzy, czy 1 raz zmiana parametrów i 10 od¬ 
czytań macierzy, macierze zostaną wyliczone na podstawie najnowszych ustawionych 
parametrów tylko raz. 

Ponadto klasy kamery są przygotowane na ich używanie jako obiekty stałe (słowo 
kluczowe const). Na przykład przekazanie do jakiejś funkcji parametru typu const 
ParamsCamera & oznacza, że funkcja ta może odczytywać dane kamery, ale nie może 
zmieniać jej ustawień. Aby mimo modyfikatora const możliwe było leniwe wartościo¬ 
wanie, podlegające mu pola są oznaczone jako mutable. 

Moduł Engine Jądro całego silnika stanowi kod znajdujący się w plikach 
Engine\Engine . hpp i Engine\Engine . cpp, zgromadzony w przestrzeni nazw engine. 
Podstawową klasą jest Engine, której jedyny, dostępny dla wszystkich obiekt zapa¬ 
miętany jest w zmiennej globalne g_Engine. Reprezentuje on cały silnik graficzny. 
Zawiera kilka ustawień, które pozwalają na wyłączanie niektórych funkcji graficz¬ 
nych, jak oświetlenie czy cienie. Oprócz tego, jego główną rolą jest przechowywanie 
kolekcji scen, z których jedna jest wybrana jako aktywna. 

Klasa EngineServices jest przeznaczona tylko do użytku wewnętrznego dla in¬ 
nych klas modułu Engine. Obiekt klasy Engine przechowuje i udostępnia pojedynczy 
obiekt tej klasy. Jego zadaniem jest dostarczanie zasobów pomocniczych potrzebnych 
w procesie renderowania, jak tekstury wykorzystywane w roli mapy cienia. Zajmuje 
się także ustawianiem stanów Direct3D i parametrów shadera. 
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Scena, czyli obiekt klasy Scene, reprezentuje „wirtualny świat” — przestrzeń 3D, 
w której umieszczone są wszystkie obiekty graficzne. Jest najobszerniejszą klasą tego 
modułu. Przechowuje wskaźniki do zawartych w niej obiektów graficznych różnego 
rodzaju i zawiera procedury zarządzające ich wydajnym renderowaniem. Dodatkowo 
posiada możliwość sprawdzania trafienia (kolizji) promienia do zawartych w niej obiek¬ 
tów. Scena zawiera następujące obiekty i parametry: 


zbiór encji typu Entity, czyli podstawowych obiektów graficznych, Encje są prze¬ 


chowywane w swobodnym drzewie ósemkowym, opisanym szerzej w rozdz. 3.13 
zbiór świateł typu BaseLight, 

zbiór kamer typu Camera, z których jedna ustawiona jest jako aktywna, 
kolekcja materiałów — pojedynczy obiekt typu MaterialCollection, 
zbiór efektów postprocessingu, 

obiekt mapy dla przestrzeni zamkniętych typu QMap oraz zbiór parametrów wy¬ 
świetlania tej mapy (czy podlega oświetleniu, czy rzuca cień, czy otrzymuje cień), 
teran dla przestrzeni otwartych typu TerrainRenderer, który obejmuje wyświe¬ 
tlanie podłoża terenu, drzew, trawy i wody, 
obiekt nieba typu BaseSky, 
obiekt opadów atmosferycznych typu Fali, 
kolor światła otoczenia (ang. Ambient Light) typu COLORF, 
wektor oznaczający siłę i kierunek wiatru typu VEC3, 

parametry mgły —jej stan (czy jest włączona), kolor i odległość, od której się 
rozpoczyna. 


Encja (ang. Entity) to podstawowy budulec sceny, dowolny obiekt potrafiący nary¬ 
sować się na ekranie i posiadający szereg parametrów, pośród których najważniejsze 
jest położenie w przestrzeni 3D. Z klasy bazowej Entity dziedziczy kilka innych klas 
rozpoznawanych za pomocą metody GetType i rzutowanych w dół, z których z kolei 
dziedziczą klasy realizujące konkretne rodzaje encji, opisane w następnym podroz¬ 
dziale. Te typy to: 

• klasa MaterialEntity (typ TYPE_MATERIAL) — obiekt, którego obraz rysowany 
jest z użyciem standardowego mechanizmu materiałów silnika. Posiada dodat¬ 
kowe parametry: 

- TeamColor to kolor charakterystyczny dla danej encji, który może wchodzić 
w interakcję z materiałem, 

- TextureMatrix to macierz transformacji współrzędnych tekstury, 

- flagi mówiące czy encja podlega oświetleniu, czy rzuca cień i czy otrzymuje 

cień, 

• klasa CustomEntity (typ TYPE_CUSTOM) — obiekt, którego obraz rysowany jest 
w niestandardowy sposób, 

• klasa HeatEntity (typ TYPE_HEAT) — niewidoczny obiekt, który renderowany 
jest do kanału Alfa celem uzyskania efektu Heat Haze, 
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• klasa TreeEntity (typ TYPE_TREE) — drzewo. 

Każda encja posiada następujące parametry: 

• transformacja opisana za pomocą wektora translacji, kwaterniona orientacji oraz 
skalara dla skalowania równomiernego, 

• encja nadrzędna i zbiór encji podrzędnych. Encje tworzą logiczne drzewo (które 
jednak nie ma nic wspólnego z drzewem ósemkowym, w którym są przecho¬ 
wywane dla optymalizacji). Dzięki temu ich transformacje są składane, co po¬ 
zwala np. na automatyczne przemieszczanie i obracanie się modeli miecza, zbroi 
i hełmu wraz z modelem ich posiadacza. Istnieje również możliwość podłączenia 
encji do wybranej kości jej encji nadrzędnej (np. miecz obraca się razem z ręką 
posiadacza), 

• stan widoczności — czy obiekt jest widoczny, czy ukryty, 

• Tag — 32-bitowa liczba całkowita do dowolnego użytku. 

Ponadto istnieje możliwość otrzymania macierzy reprezentującej transformację en¬ 
cji i odwrotność tej macierzy, jak również promień sfery otaczającej. Autor zdecydował 
się na użycie brył otaczających w kształcie sfer ze względu na prostotę i szybkość ich 
użycia. Jest to ważne szczególnie podczas obracania się obiektów, kiedy to sfera 
zachowuje swój dotychczasowy kształt i wielkość, a innego rodzaju bryły otaczające 
wymagają dodatkowej obsługi. Klasa encji posiada także funkcję wirtualną testującą 
kolizję promienia z obiektem. 

Rys. |2.14| pokazuje hierarchię klas świateł. BaseLight to klasa bazowa dla wszel¬ 
kiego rodzaju świateł. Przechowuje ona dane wspólne dla każdego światła: 

• kolor, 

• aktywność — mówi czy światło jest włączone, 

• flaga mówiąca czy światło rzuca cień, 

• flaga mówiąca, czy światło powoduje odblask, 

• flaga mówiąca, czy światło używa obliczeń Half-Lambert, 

• współczynnik jasności dla miejsc znajdujących się w cieniu. 


Klasa PositionedLight również jest abstrakcyjna. Stanowi bazę dla wszystkich 
rodzajów świateł, które mają określoną pozycję w przestrzeni. Oprócz przechowywa¬ 
nia pozycji potrafi ona także zwrócić prostokąt wyznaczający zasięg działania świa¬ 
tła w przestrzeni ekranu, używany w czasie renderowania do obcinania za pomocą 
Scissor Test przyspieszającego proces. Zwracana przy okazji wartość procentowa tego 
obszaru względem całej powierzchni ekranu może z kolei posłużyć do wyznaczenia po¬ 
ziomu szczegółowości, z jakim wyrenderowane ma być oświetlenie danym światłem, 
np. rozdzielczość używanej w jego przebiegu mapy cienia. 

Światło kierunkowe (3), reprezentowane przez klasę DirectionalLight, to świa¬ 


tło nie posiadające swojej pozycji w przestrzeni (patrz rys. 2.15 a). Rozchodzi się 
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Rys. 2.14. Diagram klas świateł. 


ono równolegle oświetlając całą scenę, tak jakby pochodziło z nieskończenie odległego 
źródła. Jest najprostsze i najmniej kosztowne obliczeniowo. Nadaje się doskonale do 
modelowania światła słonecznego. Posiada kierunek padania (znormalizowany wek¬ 
tor). Dodatkowo przechowuje odległość, która wyznacza jak daleko od kamery sięga 
cień rzucany przez to światło. Ograniczenie tego zasięgu ma kluczowe znaczenie dla 
poprawy jakości cieni. 



a) b) c) 

Rys. 2.15. Rodzaje świateł: a) światło kierunkowe, b) światło punktowe, c) światło latarki. 


Światło punktowe (3J, reprezentowane przez klasę PointLight, to światło rozcho¬ 
dzące się we wszystkich kierunkach z określonego punktu w przestrzeni (patrz rys. 


2.15 b). Może modelować oświetlenie pochodzące np. od żarówki albo płomienia 


świecy. Posiada maksymalny zasięg, do którego jego intensywność zanika wg za¬ 
leżności kwadratowej. Posiada także odległość minimalną, od której rozpoczyna się 
działanie jego cienia (odległość ta nie może wynosić 0, co wynika z budowy macierzy 
rzutowania perspektywicznego). Używanie tego światła z włączonymi cieniami jest naj¬ 
bardziej kosztowne obliczeniowo, gdyż wymaga każdorazowego renderowania sceny 
osobno do każdej z 6 ścian sześciennej mapy cienia otaczającej światło ze wszystkich 
stron. 
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Trzeci rodzaj światła to SpotLight (3j. Reprezentuje ono światło rozchodzące się 
od określonego punktu w określonym kierunku, w zakresie ograniczonym przez pe¬ 
wien kąt do obszaru w kształcie stożka (patrz rys. 2.15 c). Światło to posiada pozycję, 
zasięg i minimalną odległość cienia (podobnie jak światło punktowe), a ponadto kie¬ 
runek, kąt i flagę mówiącą, czy wraz ze wzrostem kąta jego intensywność ma płynnie 
zanikać. 

W procesie renderowania elementów sceny istnieje kilka flag typu logicznego (’tak’ 
lub 'niej, które mogą przyspieszyć bądź spowolnić ten proces. Są to: 

• Flaga SETTING_MATERIAL_SORT mówi, czy encje należy sortować wg materiału. 

• Flaga SETTING_ENTITY_OCCLUSION_QUERY mówi, czy sprawdzać widoczność en- 
cji za pomocą zapytań Occlusion Query. 

• Flaga SETTING_LIGHT_OCCLUSION_QUERY mówi, czy sprawdzać zasięg świateł za 
pomocą zapytań Occlusion Query. 

• Flaga SETTING_TREE_FRUSTUM_CULLING mówi, czy wykonywać test przecięcia 
frastuma widzenia z bryłami otaczającymi drzew. 


Na przykład jeśli scena zawiera encje rysowane każda innym materiałem, to ich 
sortowanie wg materiału nie przyniesie żadnych korzyści i jako dodatkowa operacja 
niepotrzebnie spowolni program. Jeśli natomiast do sceny dodane jest wiele encji ry¬ 
sowanych tym samym materiałem, to ich wyświetlanie jedna za drugą zminimalizuje 
liczbę potrzebnych zmian tekstury, shadera i innych ustawień Direct3D, co przyspie¬ 
szy renderowanie. Podobnie jeśli wszystkie obiekty będące w zasięgu kamery faktycz¬ 
nie są widoczne, to wykonywanie dodatkowych zapytań sprzętowych o zasłanianie 
byłoby tylko stratą czasu. Jeśli natomiast jakieś skomplikowane obiekty są w zasięgu 
frustuma kamery, ale są zasłonięte np. przez ścianę, to wykonanie takiego zapytania 
zaoszczędzi bardzo wiele czasu, którego wymagałoby ich odrysowanie. 

Zamiast ustawić wartości tych flag na stałe w kodzie silnika bądź też próbować 
wyliczać ich wartości optymalne dla danej sytuacji w jakiś sposób analityczny, au¬ 
tor przeznaczył do sterowania nimi klasę RunningOptimizer. Podstawowe założenie 
mówi, że klasa ta jest całkowicie „nieświadoma” znaczenia poszczególnych ustawień. 
Dla niej jest to tylko zbiór 4 zmiennych logicznych, którymi steruje. Wykonywana 
w każdej klatce metoda OnFrame wykonuje dwie czynności. Po pierwsze, analizuje 
czas trwania poprzedniej klatki. Po drugie, zwraca wartości zmiennych logicznych do 
zastosowania w biężącej klatce. 

Tylko tyle jest potrzebne, aby klasa automatycznie dobierała najoptymalniejsze w 
danej chwili wartości tych zmiennych. Zapamiętane są ich „aktualne” wartości i one 
są zwracane przez większość klatek pracy silnika. Raz na kilka klatek klasa „próbuje” 
jednak przestawić jedną z tych zmiennych na stan przeciwny, aby w następnej klatce 
sprawdzić, czy spowodowało to przyspieszenie renderowania. Po kilku takich pozy¬ 
tywnie zakończonych próbach „aktualny” stan danej zmiennej jest przestawiany na 
przeciwny. 
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Eksperymenty ze specjalnie przygotowanymi scenami dowiodły, że ten prosty i ogól¬ 
ny algorytm dobrze sprawdza się w praktyce. Klasa faktycznie dobiera parametry 
optymalne w danej chwili, choć robi to z kilkusekundowym opóźnieniem. Na przykład 
kiedy duża część sceny objętej zasięgiem kamery staje się zasłonięta przez umiesz¬ 
czoną tuż przed kamerą ścianę, po chwili uaktywnia się Occlusion Query znacznie 
przyspieszając renderowanie. 

Można powiedzieć, że na wysokim poziomie grafikę 3D reprezentują dwa rodzaje 
danych: kształt i wygląd powierzchni. Kształt opisany jest siatką trójkątów. Materiał 
to pojęcie reprezentujące wygląd powierzchni i sposób, w jaki reaguje ona na światło. 
W jego skład wchodzą więc takie parametry, jak używana tekstura czy też intensyw¬ 
ność odblasku. 

Sposób obsługi materiałów w silniku może być różny. W najprostszym przypadku 
materiał może opisywać pojedyncza struktura złożona ze wszystkich dopuszczalnych 
parametrów. W najbardziej zaawansowanych silnikach istnieje osobny edytor ma¬ 
teriałów, w którym sposób renderowania powierzchni można definiować bardzo ela¬ 
stycznie za pomocą edytora, używając połączonych ze sobą, wizualnych elementów. 
Autor zdecydował się na proste rozwiązanie, w których parametry materiału przecho¬ 
wuje jedna z klas, wybrana zależnie od konkretnego typu materiału. Hierarchię klas 
materiałów przedstawia rys. |2.16, 



Rys. 2.16. Diagram klas materiałów. 


BaseMaterial to abstrakcyjna klasa bazowa przechowująca parametry wspólne 
dla wszystkich materiałów: 


• Name — nazwa, 

• TwoSided — czy materiał jest dwustronny. Jeśli nie jest, włączony zostaje Back- 


face Culling, 

• CollisionType — maska bitowa określająca typ kolizji (patrz p. 


275) . 


Klasa WireFrameMaterial reprezentuje materiał rysowany w trybie szkieletowym 
— jako same krawędzie trójkątów. Posiada następujące dodatkowe parametry: 
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• Color — kolor, 

• BlendMode — tryb alfa-blendingu (zwykły, addytywny lub subtraktywny), 

• ColorMode — skąd pobierany ma być kolor (z materiału, z TeamColor encji lub 
z iloczynu obydwu). 

SolidMaterial to abstrakcyjna klasa bazowa reprezentująca wszystkie te mate¬ 
riały, które są rysowane z wypełnieniem trójkątów. Jej parametry to: 

• Dif f useTextureName — nazwa zasobu podstawowej tekstury zawierającej kolor, 

• Dif fuseColor — kolor używany, jeśli nie jest podana tekstura, 

• EmissiveTextureName — nazwa zasobu tekstury zawierającej miejsca „emitu¬ 
jące” światło. Encja nie jest tak naprawdę źródłem światła, ale te miejsca ryso¬ 
wane są w sposób niepodlegający oświetleniu, co pozwala przedstawić np. diody 
świecące na panelu komputera, 

• EnvironmentalTextureName — nazwa zasobu tekstury sześciennej używanej do 
mapowania środowiskowego (ang. Enuironmental Mapping) , adresowanej wekto¬ 
rem kierunku do kamery odbitym od powierzchni, 

• TextureAnimation —wartość logiczna mówiąca, czy współrzędne tekstury pod¬ 
legają transformacji przez macierz TextureMatrix encji. Jej użycie pozwala np. 
na przesuwanie czy rozciąganie tekstury na powierzchni obiektu, 

• ColorMode — wartość wyliczeniowa określająca, czy kolor podstawowy ma być 
brany z materiału, z iloczynu materiału przez kolor encji TeamColor bądź też z in¬ 
terpolacji między nimi za pomocą parametru pobieranego z kanału Alfa podsta¬ 
wowej tekstury. To ostatnie ustawienie pozwala zaznaczyć na teksturze wybrane 
miejsca, które mają podlegać przekolorowaniu wg koloru danej encji. Dzięki 
temu można rysować tym samym materiałem np. postacie żołnierzy dwóch wro¬ 
gich armii, które różnią się kolorem hełmu (stąd nazwa „TeamColor”). 

• FresnelColor i FresnelPower to kolor i wykładnik określające parametry efektu 
Fresnel Term. 

Klasa TranslucentMaterial reprezentuje materiał półprzezroczysty. Materiały 
półprzezroczyste są w opisywanym silniku oddzielone od całkowicie nieprzezroczy¬ 
stych, ponieważ nie mogą podlegać oświetleniu. Ta trudna decyzja projektowa po¬ 
dyktowana została problemem opisanym w p. |3.1[ Klasa przechowuje następujące 
dodatkowe parametry: 

• BlendMode — tryb alfa-blendingu, 

• AlphaMode — skąd pobierana ma być wartość przezroczystości Alfa (z materiału, 
z TeamColor encji lub z iloczynu obydwu). 

Klasa OpaąueMaterial reprezentuje najczęściej używany, całkowicie nieprzezro¬ 
czysty materiał, który może podlegać oświetleniu. Jego dodatkowe parametry to: 
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• AlphaTesting — wartość graniczna Alfa. Jeśli niezerowa, powoduje uaktywnie¬ 
nie testu alfa (ang. Alpha-Testing ), 

• Hal f Lambert — czy oświetlenie liczone ma być metodą Half-Lambert, 

• PerPixel — wartość logiczna określająca, czy oświetlenie ma być liczone dla 
wierzchołków i interpolowane na powierzchni trójkątów (metoda działająca szyb¬ 
ciej, ale wyglądająca gorzej), czy dla poszczególnych pikseli. Warto dodać, że 
większość silników udostępnia tylko jeden z tych dwóch trybów, 

• NormalTextureName — nazwa zasobu tekstury przechowującej mapę normal¬ 
nych (ang. Normal Map ), 

• SpecularMode — tryb odblasku (ang. Specular): brak, zwykły odblask lub oświe¬ 
tlenie anizotropowe (ang. Anisotropic Lighting ), 

• SpecularColor — kolor własny odblasku. Jest mnożony przez kolor światła. Na 
kolor odblasku nie ma wpływu kolor podstawowy materiału, 

• SpecularPower — wykładnik potęgi używanej do liczenia odblasku, 

• GlossMapping — wartość logiczna określająca, czy intensywność odblasku ma 
być mnożona przez wartość Alfa pobieraną z tekstury podstawowej. Dzięki tej 
funkcji możliwe jest wyznaczanie na powierzchni modelu tylko wybranych frag¬ 
mentów jako odblaskowe. 

Jak widać, kanał Alfa tekstury podstawowej może posłużyć do różnych celów, za¬ 
leżnie od typu materiału i jego ustawień: 

• W materiale półprzezroczystym typu TranslucentMaterial wyznacza stopień 
półprzezroczystości. 

• Jeśli AlphaTesting > 0, wyznacza miejsca przezroczyste odrzucane za pomocą 
testu Alfa. 

• Jeśli ColorMode jest równy COLOR_LERP_ALPHA, interpoluje między kolorem tek¬ 
stury, a kolorem TeamColor encji. 

• Jeśli GlossMapping jest równy true, opisuje intensywność odblasku. 

Obliczenia kolizji, czyli przecięć geometrycznych między bryłami w 3D są w pro¬ 
gramowaniu gier uznawane za część kodu przeznaczonego do obliczeń fizyki. Opisany 
tu program, jako silnik czysto graficzny, nie posiada więc zaawansowanych kolizji ani 
żadnej fizyki ciała sztywnego. Do obliczeń fizycznych wykorzystuje się zwykle gotowe 
silniki, takie jak ODE, Newton, PhysX czy Havok. 

Tematu obliczeń kolizji nie sposób jednak do końca oddzielić od grafiki. W nie¬ 
których przypadkach do tych obliczeń potrzebne są te same dane i procedury, które 
wykorzystywane są do renderowania grafiki. Na przykład w grze typu FPS (ang. First 
Person Shooter — strzelanka z perspektywy pierwszej osoby) obliczenia trafienia kulą 
z pistoletu musi być dokonane dokładnie, a więc z pojedynczymi trójkątami obiektów 
ustawionymi w aktualnej pozycji, być może sterowanej przez animację szkieletową. 
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Dlatego opisywany silnik posiada funkcję służącą do liczenia kolizji promienia 
z zawartością sceny. Ponieważ nie każdy obiekt musi reagować na każdy test koli¬ 
zji, wprowadzone zostało pojęcie typu kolizji CollisionType. Jest to wartość typu 
uint interpretowana jako maska bitowa. Domyślne flagi przeznaczone do niej to: 
COLLISION_PHYSICAL oznaczająca kolizję fizyczną, COLLISION_OPTICAL oznaczająca 
kolizję optyczną i COLLISION_BOTH oznaczająca obydwa rodzaje kolizji. Każdy mate¬ 
riał przechowuje typ kolizji, na który reaguje. Dzięki typom kolizji można utworzyć 
takie obiekty, jak np. obiekt niewidzialny i przepuszczający światło lasera, ale reagu¬ 
jący na uderzenie albo hologram, który nie przepuszcza światła, ale pozwala obiektom 
przez niego przechodzić. 

Klasa sceny dostarcza metodę o nagłówku: 

COLLISION_RESULT RayCollision(COLLISION_TYPE CollisionType, 
const VEC3 SRayOrig, const VEC3 &RayDir, 
float *OutT, Entity **OutEntity); 

Zwraca ona rodzaj obiektu, z którym nastąpiła kolizja: COLLISION_RESULT_NONE 
to brak kolizji, COLLISION_RESULT_MAP to kolizja z mapą, 

COLLI SION_RESULT_TERRAIN to kolizja z terenem, COLLI SI ON_RESULT_ENTITY to ko¬ 
lizja z encją. Metoda zwraca też przez parametry wskaźnikowe encję, z którą nastąpiła 
kolizja oraz odległość kolizji, wyrażona w wielokrotnościach długości wektora RayDir. 

Implementacja tej kolizji opiera się na metodzie abstrakcyjnej zdefiniowanej w kla¬ 
sie bazowej encji: 

virtual bool RayCollision(COLLISION_TYPE Type, 

const VEC3 SRayOrig, const VEC3 &RayDir, float *OutT) = 0; 

Zadaniem klasy pochodnej jest dostarczyć jej implementacji, która oblicza precy¬ 
zyjną kolizję promienia z kształtem obiektu danego rodzaju. Scena, przed wywoła¬ 
niem tej metody dla danej encji, upewnia się najpierw czy promień koliduje ze sferą 
otaczającą tą encję, a także przekształca parametry promienia z globalnego układu 
współrzędnych świata do układu lokalnego danej encji mnożąc je przez odwrotność 
macierzy przekształcenia tej encji. 

Klasy encji Kod zgromadzony w plikach Engine\Entities . hpp 
i Engine\Entities. cpp dostarcza klas implementujących różne rodzaje encji, po¬ 
chodnych od klasy Entity. 

Klasa res : :QMesh jest zasobem przechowującym siatkę wczytaną z pliku QMSH. 
Klasa QMeshEntity jest encją przechowującą wskaźnik do takiego zasobu. O ile sam 
zasób siatki udostępnia jedynie jej dane i metadane oraz potrafi obliczyć macierze ko¬ 
ści dla podanej animacji i czasu, o tyle encja zajmuje się odrysowaniem tej siatki oraz 
pamięta stan jej animacji. Klasa QMeshEntity jest więc podstawową klasą obiektu 
graficznego, reprezentującą instancję siatki ustawioną na scenie. 
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Jeśli siatka posiada szkielet, w każdej chwili odtwarzana może być zero, jedna 
lub dwie animacje. Do wyłączenia animacji służy metoda ResetAnimation. Do uru¬ 
chomienia animacji służy metoda SetAnimation. Możliwe jest zakolejkowanie jednej 
animacji do otworzenia po zakończeniu bieżącej za pomocą metody QueueAnimation. 
Możliwe jest też płynne przejście (interpolacja) między animacją bieżącą i nową. Służy 
do tego metoda BlendAnimation. To bardzo ważne, bo dzięki tej funkcjonalności 
możliwe jest np. po puszczeniu klawisza klawiatury przerwanie animacji „Idzie” w do¬ 
wolnym momencie i płynne przejście do animacji spoczynkowej "Stoi” bez nagłego 
przeskoku. Dzięki podaniu dodatkowych flag bitowych typu ANIM_MODE możliwe jest 
zapętlenie animacji, a także jej odtwarzanie wstecz lub na przemian w obydwie strony. 
Ponadto sterować można fazą (czasem początkowym), prędkością i bieżącym czasem 
animacji. 

Siatka QMSH składa się z fragmentów, a każdy ma zapisaną nazwę materiału. 
Klasa QMeshEntity automatycznie pobiera materiały poszczególnych fragmentów na 
podstawie tych nazw i używa tych materiałów do renderowania. Można jednak zmie¬ 
niać materiał używany w danym fragmencie danej encji za pomocą metod takich jak 

SetCustomMaterial. 

Klasa QuadEnt±ty reprezentuje umieszczony w przestrzeni 3D prostokąt zbudo¬ 
wany z dwóch trójkątów — tzw. quad. Jego powierzchnia może być rysowana do¬ 
wolnym materiałem. Jego kształtem steruje szereg parametrów. Najważniejsza jest 
możliwość pracy jako tzw. billboard — prostokąt obrócony zawsze przodem do ka¬ 
mery. Mechanizm ten wykorzystywany był od dawna w grafice 3D do umieszczania 
w przestrzeni płaskich obrazów. Pierwsze gry trójwymiarowe (np. Doom) w ten sposób 
pokazywały postacie przeciwników. Obecnie jest to rzadziej spotykane, ale billboard 
może znaleźć wiele zastosowań. Parametry przechowywane przez klasę to: 

• DegreesOfFreedom — liczba stopni swobody: 0 oznacza prostokąt zorientowany 
zawsze zgodnie z wektorami RightDir i UpDir, 1 oznacza automatyczne obraca¬ 
nie w kierunku kamery wokół osi pionowej (Y ), 2 oznacza automatyczne obraca¬ 
nie w kierunku kamery wokół dwóch osi, 

• UseRealDir — wartość logiczna określająca, czy jako kierunek do którego ma 
być automatycznie obracany prostokąt użyty ma zostać prawdziwy kierunek od 
środka prostokąta do kamery (true), czy kierunek patrzenia kamery niezależny 
od pozycji danej encji na ekranie (false), 

• RightDir i UpDir to wektory znormalizowane wyznaczające kierunek „w prawo” 
i „do góry”, według którego prostokąt ma być zorientowany, 

• Tex to zakres koordynatów tekstury, która nakładana jest na prostokąt, 

• HalfSizeto połowa szerokości i wysokości prostokąta. 

Subtelne różnice w sposobie automatycznego obracania się prostokąta w kierunku 
kamery zależnie od parametrów DegreesOfFreedom i UseRealDir najlepiej jest zilu- 
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strwać — pojazuje je zrzut ekranu ze specjalnie przygotowanej sceny rys. 4.6, Imple¬ 
mentację algorytmu wyznaczającego orientację prostokąta zawiera funkcja 

CalcBillboardDirections. 

Klasa TextEntity reprezentuje tekst umieszczony w przestrzeni 3D. Jej działanie 
podobne jest od klasy QuadEntity. Podobnie jak w niej, tekst również może być zo¬ 
rientowany na stałe w kierunku wyznaczonym przez wektory RightDir i UpDir bądź 
obracać się zawsze w kierunku kamery wg jednego lub dwóch stopni swobody. Po¬ 
nadto dostępne są wszelkie możliwości formatowania tekstu dostępne również w mo¬ 
dule Gfx2D (automatyczne dzielenie na wiersze na granicy słowa, dosunięcie pionowe 
i poziome, podkreślenie, przekreślenie itd.), ponieważ klasa korzysta z funkcjonalno¬ 
ści zasobu czcionki (patrz p. 2.4) . Rozmiar czcionki (wysokość liter) jest określany 
w jednostkach globalnego układu współrzędnych. 

StripeEntity to abstrakcyjna klasa bazowa, która reprezentuje wąski, podłużny 
pasek trójkątów w przestrzeni 3D ułożony wzdłuż określonej ścieżki. Przykłady poka¬ 
zuje rys. 4.7[ 

Zadaniem klasy pochodnej jest przechowywanie i zwracanie sekwencji punktów 
wyznaczających tą ścieżkę. Ponieważ „pasek”, do efektownego przedstawienia na 
ekranie, musi posiadać grubość większą niż jeden piksel, specjalny algorytm układa 
trójkąty wzdłuż tej ścieżki tak, aby były one zorientowane przodem do kamery. Nie dla 
każdego przypadku możliwe jest wyznaczenie takich trójkątów, ale używany do tego 
algorytm, zawarty w metodzie DrawFragmentGeometry, dla większości rzeczywistych 
sytuacji działa dostatecznie dobrze tworząc niewiele widocznych zgięć. 

Pasek jest rysowany z użyciem wybranego materiału. Koordynaty tekstury na jego 
powierzchni można ustawić, a także włączyć ich automatyczną animację w sposób 
płynny (co powoduje efekt przewijania) i/lub skokowy. 

Klasy pochodne to: 


• LineStripeEntity to złożona z prostych odcinków łamana łącząca podaną se¬ 
kwencję punktów, 

• EllipseStripeEntity to krzywa zamknięta reprezentująca elipsę, której orien¬ 
tację wyznaczają dwa wektory promieni, 

• UTermEntity to otwarta lub zamknięta krzywa parametryczna opisana obiektem 
klasy Uterm3. Uterm (od ang. Uniwersał Term ) to funkcja parametru t opisana 
wzorem: 


v — A 2 • t 2 + Ai ■ t + 4o + f ?2 ■ sin(f?i • t + (2.1) 

Funkcja ta, wyznaczana dla wartości skalarnej lub wektorowej, pozwala za po¬ 
mocą 6 współczynników opisać bardzo szeroki wachlarz różnych kształtów, od 
linii prostej i paraboli, poprzez sinusoidę, aż po różnego rodzaju spirale w prze¬ 
strzeni 3D. Klasy przechowujące te współczynniki i wyznaczające wg wydajnego 
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algorytmu wartość funkcji dla podanego parametru to Uterm, Uterm2, Uterm3 
i Uterm4. 

• Klasa CurveEntity reprezentuje krzywą w przestrzeni 3D wyznaczają przez se¬ 
kwencję punktów. Dostępne są trzy rodzaje krzywych: kwadratowa (każdy seg¬ 
ment wyznaczają 3 punkty), krzywa Beziera (każdy segment wyznaczają 4 punkty) 
oraz krzywa B-spline. 


Klasa ParticleEntity reprezentuje efekt cząsteczkowy (ang. Particie Ęffect) 157). 
Jest to efekt typu stanowego (patrz p. o- Do rysowania cząstek używa alfa- 
blendingu i podanej tekstury. Podczas tworzenia obiektu trzeba podać liczbę czą¬ 
steczek. Włączenie funkcji LOD (od ang. Level oj Detail) powoduje, że zależnie od 
odległości encji od kamery rysowany jest tylko pewien procent spośród wszystkich 
cząstek. Dokładne omówienie znaczenia parametrów struktury PARTICLE_DEF opisu¬ 
jących efekt oraz sposobu jego renderowania na GPU znajduje się w p. 3.5 Przykła¬ 


dowe efekty działania prezentuje zrzut ekranu 4.8 


Klasy efektów postprocessingu Kod zgromadzony w plikach 

Engine\Engine_pp . hpp i Engine\Engine_pp . cpp dostarcza klas implementujących 
efekty postprocessingu. W zaawansowanym silniku platforma do definiowania takich 
efektów powinna być uogólniona, tak aby można było łatwo dodawać nowe efekty wy¬ 
prowadzając klasy pochodne od pewnej klasy bazowej efektu bądź nawet definiować 
je w całości za pomocą specjalnych plików tekstowych czy dedykowanego edytora. 
Efekty tego rodzaju są jednak bardzo różnorodne i każdy z nich wymaga innych czyn¬ 
ności. Dlatego w celu uproszczenia implementacji, autor zdecydował się na osobne 
klasy realizujące poszczególne efekty postprocessingu, z których każda ma własny 
interfejs dostosowany do jego wymagań. 

Klasy zdefiniowane przez moduł to: 

• PpEf fect — klasa bazowa efektów postprocessingu. Nie wykorzystuje ona poli¬ 
morfizmu i nie definiuje jednolitego interfejsu, a jedynie dostarcza implementacji 
kilku procedur wspólnych dla niektórych efektów, jak wyrenderowanie prosto¬ 
kąta rozciągniętego na całej powierzchni ekranu (ang. Fullscreen Quad), 

• PpColor — prosty efekt zamalowania całego ekranu w sposób półprzezroczysty 
na wybrany kolor, 

• PpTexture — prosty efekt zamalowania całego ekranu w sposób półprzezroczy¬ 
sty wybraną teksturą, 

• PpFunction — efekt przekształcenia całego obrazu za pomocą funkcji matema¬ 
tycznej , 

• PpToneMapping — efekt Tonę Mapping, 

• PpBloom — efekt Bloom, 

• PpFeedback — efekt sprzężenia zwrotnego, 

• PpLensFlare — efekt błysku soczewek. 
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Sposób implementacji poszczególnych efektów postprocessingu opisuje rozdz. 3.6 


Klasy dla przestrzeni otwartych Ważną część silnika stanowi kod renderujący 
poszczególne elementy przestrzeni otwartych — teren, niebo, wodę, drzewa, trawę 
i opady atmosferyczne. 

Kod zgromadzony w plikach Engine\Fall. hpp i Engine\Fall. cpp stanowi imple¬ 
mentację efektu opadów atmosferycznych (np. deszcz, śnieg). Za jego realizację odpo¬ 
wiada klasa Fali. Utworzenie obiektu tej klasy wymaga podania wypełnionej struk¬ 
tury FALL_EFFECT_DESC, która opisuje parametry efektu. Sposób realizacji efektu 


opadów atmosferycznych opisuje rozdz. 3.8 


Kod zgromadzony w plikach Engine\Grass . hpp i Engine\Grass . cpp służy do ren- 
derowania trawy i innych niskich obiektów gęsto rozmieszczonych na powierzchni te¬ 
renu (np. kwiaty, kamienie). Utworzenie obiektu klasy Grass wymaga podania nazwy 
pliku tekstowego w specjalnym formacie opisującym parametry efektu, a także nazwę 
pliku specjalnej tekstury gęstości (ang. Density Map ) przedstawiającej rozmieszczenie 
trawy na terenie. Sposób realizacji trawy opisuje rozdz. |3.9 


Kod zgromadzony w plikach Engine\Sky . hpp i Engine\Sky . cpp służy do rendero- 
wania nieba. BaseSky to abstrakcyjna klasa bazowa służąca do renderowania nieba. 
Dziedzicząca po niej klasa SolidSky rysuje proste tło w jednolitym kolorze. Klasa 
SkyboxSky używa do rysowania tła sześciu tekstur mapując je na wewnętrznych po¬ 
wierzchniach ścian sześcianu otaczającego kamerę. Jest to tzw. sześcian nieba (ang. 
Skybox). Najbardziej złożona spośród podklas — ComplexSky — renderuje proce¬ 
duralnie generowane niebo z gradientem na tle, chmurami oraz ciałami niebieskimi 


takimi jak Słońce czy Księżyc. Sposób implementacji tej klasy opisuje rozdz. 3.10 


Kod zgromadzony w plikach Engine\Terrain . hpp i Engine\Terrain. cpp służy 
do renderowania terenu. Utworzenie obiektu klasy Terrain wymaga podania szeregu 
parametrów. Pośród nich jest nazwa pliku specjalnej tekstury zawierającej mapę wy¬ 
sokości (ang. Heightmap), innej tekstury obrazującej rozmieszczenie poszczególnych 
form terenu (np. trawy, piasku, śniegu) oraz pliku tekstowego w specjalnym forma¬ 
cie opisującym te formy terenu. Na podstawie tych danych klasa generuje podczas 
inicjalizacji siatkę trójkątów tworzącą teren w przestrzeni 3D. Ponieważ jest to pro¬ 
ces kosztowny obliczeniowo, wyliczona za pierwszym razem siatka jest zapisywana 
w osobnym pliku binarnym celem ponownego użycia. Sposób implementacji terenu 


opisuje rozdz. 3.7 


Kod zgromadzony w plikach Engine\Trees . hpp i Engine\Trees . cpp służy do 
renderowania drzew. Drzewa są generowane proceduralnie. Obiekt klasy Tree re¬ 
prezentuje pojedynczy gatunek drzewa i umożliwia jego renderowanie. Utworzenie 
takiego obiektu wymaga podania wypełnionej struktury TREE_DESC, opisującej para¬ 


metry kształtu i wyglądu drzewa. Sposób implementacji drzew opisuje rozdz. 3.11 


Kod zgromadzony w plikach Engine\Water . hpp i Engine\Water . cpp służy do ren- 
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derowania powierzchni wody. Klasa bazowa WaterBase przechowuje parametry opi¬ 
sujące jej wygląd i zawiera kod odpowiedzialny za rendering. Dziedzicząca z niej klasa 
WaterEntity jest encją wyświetlającą zorientowany w płaszczyźnie poziomowej pro¬ 
stokąt rysowany jako powierzchnia wody. To pozwala wstawić obszar wody w dowolne 
miejsce sceny, także do scen typu zamkniętego. Druga podklasa — TerrainWater — 
rysuje wodę jako część terenu. Sposób implementacji renderowania wody opisuje 
rozdz. 13. 121 

Za renderowanie przestrzeni otwartych odpowiada klasa TerrainRenderer zde¬ 
finiowana w pliku Engine\Engine. hpp. Przechowuje ona obiekty klas: Terrain, 
Grass, TerrainWater oraz Tree i organizuje proces ich renderowania. Obiekt tej 
klasy jest z kolei przechowywany przez scenę. 


Klasy dla przestrzeni zamkniętych Kod zgromadzony w plikach Engine\QMap. hpp 
i Engine\QMap. cpp to klasa QMap. Jest ona typem zasobu. Służy do wczytywania, 
przechowywania i udostępniania danych o mapie typu Indoor (przestrzeń zamknięta). 
Mapa to siatka trójkątów, podobnie jak model 3D. Różni się jednak od modeli zarówno 
pod względem znaczeniowym (przedstawia pomieszczenia i korytarze, których wnętrza 
przemierza użytkownik), jak i pod względem technicznym (stosuje podział przestrzeni, 
aby można było rysować tylko widoczną część, a nie całość geometrii). Informacje na 


temat formatu QMAP zawiera rozdz. 3.14 


Mapa może zostać utworzona w programie graficznym (np. Blender, 3ds Max, 
Maya) lub specjalnym edytorze map (np. QuArK, DeleD). Musi zostać zapisana w za¬ 
projektowanym przez autora formacie pliku: QMAP. W tym celu napisana została 
wtyczka eksportująca siatkę z programu graficznego Blender do formatu tymczaso¬ 
wego QMAP.TMP, a program narzędziowy (p. 2.6} przetwarza taki plik do formatu 
docelowego QMAP. 

Za renderowanie mapy, której dane udostępnia opisana wyżej klasa zasobu, od¬ 
powiada klasa QMapRenderer zdefiniowana w pliku Engine\Engine. cpp. Obiekt 
tej klasy jest przechowywany przez scenę, analogicznie do klasy TerrainRenderer 
w przypadku scen typu otwartego. 


2.6. Narzędzia i eksportery 

Komercyjne silniki gier, takie jak Unreal Engine, dostarczane są razem z zestawem 
programów narzędziowych i edytorów wspierających tworzenie gier. Autor opisanego 
tu silnika graficznego zdecydował się, dla uproszczenia, zrezygnować z tworzenia ja¬ 
kichkolwiek programów tego typu. Większość danych graficznych podaje się więc bądź 
w postaci plików tekstowych w specjalnie zaprojektowanych formatach, bądź w po¬ 
staci tekstur wyznaczających za pomocą kolorów swoich pikseli np. mapę wysokości 
terenu, rozmieszczenie na terenie drzew czy trawy. 
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Pewne dane muszą być jednak dostarczone w postaci binarnej. Dotyczy to zwłasz¬ 
cza siatek trójkątów przedstawiających modele. Ponieważ silnik wykorzystuje własny 
format plików modeli QMSH, potrzebna jest możliwość zapisywania danych w tym for¬ 
macie. Tworzenie własny formatów modeli jest częstą praktyką i problem ten rozwią¬ 
zywany jest zazwyczaj za pomocą eksportera, czyli wtyczki do programu graficznego 
3D potrafiącej zapisać model od razu w formacie docelowym. 

Autor wybrał inne rozwiązanie. Dla darmowego programu graficznego 3D — Blen- 
der — napisane zostały w języku Python wtyczki eksportujące siatkę do formatów 
pośrednich, nazwanych QMSH.TMP i QMAP.TMP. Są to pliki tekstowe przechowujące 
potrzebne dane w takiej postaci, w jakiej pobrane zostały wprost z Blendera. Dzięki 
temu wtyczki są bardzo proste. Ich kod znajduje się w katalogu Plugins\Blender. 

Dalsze przetwarzanie tekstowych plików w formatach pośrednich na pliki binarne 
w formatach docelowych odbywa się w osobnym programie konsolowym, napisanym 
już w C++. Nosi on nazwę Tools, a jego kod źródłowy zgromadzony jest w katalogu 
src\Tools. Sterowanie programem odbywa się za pomocą odpowiednich parametrów 
wiersza poleceń. Są trzy rodzaje dostępnych operacji: dotyczące siatek, map i tekstur. 
Pełna lista dopuszczalnych parametrów znajduje się w pliku doc\Tools\Tools . txt. 

Operacje na siatkach Formatem pliku wejściowego siatki może być plik pośredni 
QMSH.TMP lub plik QMSH. Formatem wyjściowym jest zawsze QMSH. Siatka pod¬ 
czas wczytywania z formatu QMSH.TMP jest przetwarzana do formatu docelowego. W 
skład tego procesu przetwarzania wchodzą różnorodne obliczenia, w tym przekształce¬ 
nie układu współrzędnych ze stosowanego przez Blender (prawoskrętny, X w prawo, 
Y w głąb, Z do góry) do stosowanego przez silnik, standardowego dla DirectX (lewo- 
skrętny, X w prawo, Y do góry, Z w głąb). 

Wyliczane są też wektory normalne, a na życzenie także styczne (Tangent i Binor- 
mal). Do obliczeń tych użyta została biblioteka C++ firmy NVIDIA — NvMeshMender. 
Bierze ona pod uwagę kąt między powierzchniami pozwalając na określenie granicy, 
poniżej której krawędź uznana zostaje za ostrą i wektory normalne nie są wygładzane. 
Jak ważna jest ta funkcja, obrazuje rys. |2.17 

Dodatkowo dostępne są parametry przekształcające siatkę, np. dokonujące trans¬ 
lacji, rotacji, skalowania, centrowania na średniej lub medianie z pozycji wszystkich 
wierzchołków, przekształcania takiego aby siatka mieściła się wewnątrz podanego pro¬ 
stopadłościanu, skalowanie czasu animacji itd. Oprócz tego możliwe są proste opera- 
cje typu zmiana nazwy albo usunięcie podsiatki, animacji czy materiału. 

Parametry /I oraz /v umożliwiają wypisanie na konsoli informacji o przetwarzanej 
siatce — liczby trójkątów, wierzchołków, animacji, kości, wielkości bryły otaczającej, 
listy podsiatek itd. Przykładowe wywołanie programu w celu przetworzenia siatki 
może wyglądać następująco: 
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Rys. 2.17. Wpływ sposobu obliczania wektorów normalnych na oświetlenie siatki, a) Brak 
wygładzania normalnych, b) Całkowite wygładzenie normalnych, c) Wygładzenie normalnych 

bazujące na granicznym kącie krawędzi. 


Tools.exe /Mesh /i=Monster01.qmsh.tmp 

/TransformToBox=-0.5,-0.5,-0.5;0.5,0.5;0.5 
"/ScaleTime=0.2|Animation:AnimacjaAtak" 

/o=Monster.qmsh /v /Tangents /MaxSmoothAngle=45 

Operacje na mapach Przetwarzanie mapy z formatu pośredniego QMAP.TMP do for¬ 
matu docelowego QMAP odbywa się w analogiczny sposób, jak przetwarzanie modeli. 
Służy do niego przełącznik /Map. Dodatkowo dostępne są opcje dostosowujące para¬ 
metry drzewa ósemkowego stosowanego do podziału przestrzeni mapy, np. maksy¬ 
malna głębokość drzewa. 


Operacje na teksturach Podczas opracowania elementów graficznych wykorzysta¬ 
nych do zaprezentowania możliwości silnika wyniknęła potrzeba przetwarzania tek¬ 
stur pewnymi algorytmami, których nie oferują zwyczajne programy graficzne. Dla¬ 
tego opisany tu program konsolowy wzbogacony został o możliwość przetwarzania 
tekstur. 

Jego możliwości w tym zakresie nie dublują funkcji dostępnych w zwyczajnych pro¬ 
gramach graficznych. Nie ma więc opcji do regulowania jasności, kontrastu czy nasy¬ 
cenia kolorów. Parametr /Swizzle pozwala na swobodną zamianę kanałów tekstury 
między sobą (czerwony, zielony, niebieski, alfa), ich kopiowanie oraz wypełnianie ze¬ 
rami bądź jedynkami. Parametr /SharpenAlpha służy do niwelowania niepożądanego 
efektu „otoczki” wokół krawędzi przezroczystego obiektu stosującego do renderowa- 
nia test Alfa, często wykorzystywany przy przedstawianiu roślin. Użyty w tym celu 
wzór pochodzi z l70t . Parametr /ClampTransparent wypełnia kolory pikseli przezro¬ 
czystych kolorem najbliższego nieprzezroczystego piksela w poziomie lub w pionie, co 
zapobiega „przeciekaniu” kolorów pikseli przezroczystych przy mipmappingu. Użycie 


dwóch ostatnich parametrów ilustruje rys. 2.18 
Polecania użyte do ich uzyskania to: 


89 








2. Architektura silnika 



Rys. 2.18. Przetwarzanie tekstury z użyciem programu Tools. a) Oryginalne zdjęcie b) 
Tekstura z wyciętym obiektem, pokazana na tle koloru czarnego, ujawnia białą otoczkę na 
krawędziach, c) Zastosowanie parametru /SharpenAlpha niweluje niepożądany efekt, d) 
Zastosowanie parametru /ClampTransparent ostatecznie przygotowuje teksturę do 

zastosowania w renderowaniu rośliny. 


Tools.exe /Texture 
/o=texture02.tga 
Tools.exe /Texture 
/o=texture03.tga 


/i=texture01.tga /SharpenAlpha=FFFFFF 
/AlphaThreshold=l92 

/i=texture02.tga /ClampTransparent 
/AlphaThreshold=l92 
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Rozdział 3 


Implementacja silnika 


Ten rozdział przedstawia szczegóły implementacyjne wybranych efektów graficz¬ 
nych i innych ważniejszych elementów silnika. Nie sposób opisać dokładnie wszyst¬ 
kich algorytmów użytych w kodzie tej pracy. 


3.1. Proces renderowania 


Algorytm renderowania Właściwy proces renderowania sceny rozpoczyna się od 
metody Scene: :Draw w pliku Engine, cpp. Jej głównym zadaniem jest jak najwy¬ 
dajniej zorganizować cały proces wplatając w odpowiednie miejsca wywołania służące 
do wykonania poszczególnych efektów postprocessingu. Na uwagę zasługuje decyzja 
podejmowana przez tą funkcję, czy potrzebne jest renderowanie sceny do tekstury, czy 
też można odrysować obiekty sceny wprost na buforze ramki (ang. Back Buffer ). Ren¬ 
derowanie do tekstury pomocniczej jest wykonywane, jeśli włączony jest co najmniej 
jeden efekt postprocessingu, który tego wymaga. Wówczas obraz z tej tekstury zostaje 
w pewnym momencie przerysowany do bufora ramki za pomocą shadera PpShader 
(opisanego w p. 3.6) , który wykonuje na pikselach obrazu wszystkie potrzebne opera¬ 
cje. Zarys omówionej metody w pseudokodzie przedstawia poniższy listing. 


"function Scene::Draw" 

Spytaj RunningOptimizer o ustawienia renderowania 
Pobierz DRAW_DATA 
if (postprocessing wyłączony) : 

Rysuj scenę 
else: 

if (efekty postprocessingu nie wymagają, renderowania do tekstury): 
Rysuj scenę 

if (efekt błysku soczewek włączony): 

Zadaj zapytanie o widoczność słońca 
else: 

Pobierz teksturę celu renderowania 

Dla tekstury ustawionej jako cel renderowania: 

Rysuj scenę 

if (efekt błysku soczewek włączony): 

Zadaj zapytanie o widoczność słońca 
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if (co najmniej jedna encja ciepła widoczna): 

Wyczyść kanał alfa celu renderowania 
Wyrenderuj encje ciepła do kanału alfa 
if (efekt Tonę Mapping włączony): 

Oblicz jasność sceny 
if (efekt Bloom włączony): 

Przygotuj teksturę Bloom 

Przerysuj teksturę do bufora ramki za pomocą shadera PpShader 
if (efekt Bloom włączony): 

Narysuj efekt Bloom 

if (efekt sprzężenia zwrotnego włączony) : 

Wykonaj efekt sprzężenia zwrotnego 
if (efekt błysku soczewek włączony): 

Wylicz intensywność błysku na podstawie widoczności słońca 
if (intensywność błysku > 0): 

Rysuj błysk soczewek 

if (efekt rysowania tekstury na ekranie włączony): 

Rysuj teksturę na ekranie 
if (efekt rysowania koloru na ekranie włączony): 

Rysuj kolor na ekranie 

Struktura DRAW_DATA przechowuje listy elementów sceny przeznaczonych do wy- 
renderowania w danej klatce i służy do przekazywania tych danych między poszcze¬ 
gólnymi wywołaniami rysującymi. Jej pola wypełniane początkowo to: 

1. std: :vector<MaterialEntity*> MaterialEntities — lista wskaźników na 
encje widoczne w zasięgu kamery, które używają do renderowania mechanizmu 
materiałów. 

2. std: : vector<CustomEntity*> CustomEntities — lista wskaźników na encje 
widoczne w zasięgu kamery rysowane w sposób niestandardowy. 

3. std: : vector<HeatEntity*> HeatEntities — lista wskaźników na encje cie¬ 
pła widoczne w zasięgu kamery. 

4. std: : vector<TREE_DRAW_DESC> Trees — lista struktur opisujących widoczne 
w zasięgu kamery drzewa. 

5. QMapRenderer : : FRAGMENT_DESC_VECTOR MapFragments — lista struktur opi¬ 
sujących widoczne w zasięgu kamery fragmenty mapy. 

6. std: : vector<uint> TerrainPatches — lista indeksów do fragmentów terenu 
widocznych w zasięgu kamery. 

7. std: : vector<SpotLight*> SpotLights — lista świateł latarki, których zasięg 
działania koliduje z zasięgiem kamery. 

8. std: : vector<PointLight*> PointLights — lista świateł typu punktowego, 
których zasięg działania koliduje z zasięgiem kamery. 


Na ich podstawie wypełniane są w dalszym etapie renderowania kolejne pola: 

1. std: : vector<ENTITY_FRAGMENT> OpaąueEntityFragments — lista struktur opi¬ 
sujących wszystkie fragmenty widocznych encji materiałowych renderowane ma¬ 
teriałem typu nieprzezroczystego. Będą one rysowane w kolejności posortowanej 
wg materiału. 
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2. std: : vector<ENTITY_FRAGMENT> TranslucentEntityFragments—lista struk¬ 
tur opisujących wszystkie fragmenty widocznych encji renderowanych materia¬ 
łem typu półprzezroczystego i szkieletowego, wraz z encjami rysowanymi w spo¬ 
sób niestandardowy. Będą one rysowane w kolejności posortowanej wg odległo¬ 
ści od kamery. 

Wspomniana na powyższym listingu procedura pobierania struktury DRAW_DATA 
jest zaimplementowana w postaci metody Scene: : CreateDrawData. Jej działanie 
w pseudokodzie ilustruje następujący listing: 

"function Scene::CreateDrawData" 

Wyczyść listy w DrawData 

Entities = Octree.Wszystkie encje widoczne w zasięgu kamery 
foreach (Encja in Entities): 
if (Encja is MaterialEntity): 

DrawData.MaterialEntities.Dodaj(Encja) 
else if (Encja is CustomEntity): 

DrawData.CustomEntities.Dodaj(Encja) 
else if (Encja is HeatEntity): 

DrawData.HeatEntities.Dodaj(Encja) 
else if (Encja is TreeEntity): 

DrawData.Trees.Dodaj(Struktura opisująca drzewo z Entity) 
if (Mapa != nuli): 

DrawData.MapFragments = Mapa.Wszystkie fragmenty w zasięgu kamery 
DrawData.MapFragments.Sortuj_wg_materiału 
if (Teren != nuli): 

DrawData.TerrainPatches = Teren.Indeksy widocznych fragmentów 
DrawData.Trees.Dodaj(Teran.Struktury opisujące drzewa w zasięgu 
kamery) 

if (Oświetlenie włączone): 

foreach (Światło in Wszystkie światła punktowe na scenie): 
if (Światło.Aktywne i Światło.Kolor != CZARNY): 

if (Zasięg działania światła przecina zasięg widzenia kamery): 
DrawData.PointLights.Dodaj(Światło) 
foreach (Światło in Wszystkie światła Spot na scenie): 
if (Światło.Aktywne i Światło.Kolor != CZARNY): 

if (Zasięg działania światła przecina zasięg widzenia kamery): 
DrawData.SpotLights.Dodaj(Światło) 

Wspomniana na pierwszym listingu procedura Rysuj scenę jest zaimplemento¬ 
wana w postaci metody Scene : : DrawAll. Jej zadaniem jest odrysowanie na ustawio¬ 
nym aktualnie celu renderowania (czyli bezpośrednio na buforze ramki bądź na tek¬ 
sturze pomocniczej) wszystkich widocznych obiektów sceny, których listy otrzymuje 
w strukturze DRAW_DATA. Przebieg tego algorytmu ilustruje w pseudokodzie poniższy 
listing: 

"function Scene::DrawAll" 
if (Niebo != nuli) 

Niebo.Rysuj 
Wyczyść Z-bufor 
if (Mapa != nuli): 

foreach Fragment in DrawData.MapFragments: 

Mapa.Rysuj_fragment(Fragment, Przebieg bazowy) 
if (Teren != nuli): 

foreach Fragment in DrawData.TerrainPatches: 

Teren.Rysuj_fragment(Fragment, Przebieg bazowy) 
if (RunningOptimizer.Wykonywać_testy_zasłaniania_encji): 
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Wykonaj testy zasłaniania encji 
if (RunningOptimizer.Wykonywać_testy_zasłaniania_świateł): 

Wykonaj testy zasłaniania świateł 
Spisz fragmenty encji materiałowych w DrawData 
if (RunningOptimizer.Sortować_wg_materiału): 

DrawData.OpaąueEntityFragments.Sortuj_wg_materiału 
foreach (Fragment in DrawData.OpaąueEntityFragments): 

Rysuj fragment, Przebieg bazowy 
DrawData.Trees.Sortuj_wg_gatunku_drzewa 
foreach (Drzewo in DrawData.Trees): 

Drzewo.Rysuj 
if (Teren != nuli): 

Teren.Rysuj_trawę 
if (Oświetlenie włączone): 

if (Światło_kierunkowe != nuli i Światło_kierunkowe.Aktywne i 
Światło_kierunkowe.Kolor != CZARNY): 

if (Shadow mapping włączony i Światło_kierunkowe.RzucaCień): 

Rysuj do shadow mapy światła kierunkowego 
if (Mapa != nuli i Mapa.Używa_oświetlenia): 
foreach (Fragment in DrawData.MapFragments): 

Mapa.RysujFragment(Fragment, Przebieg światła kierunkowego) 
if (Teren != nuli): 

foreach (Fragment in DrawData.TerrainPatches): 

Teren.RysujFragment(Fragment, Przebieg światła kierunkowego) 
foreach (Encja in DrawData.OpaąueEntityFragments): 

Encja.Rysuj(Przebieg światła kierunkowego) 
foreach (Światło in DrawData.PointLights): 

if (Światło.Aktywne i Światło.Kolor != CZARNY): 

if (Zasięg działania światła przecina zasięg widzenia kamery): 
ScissorRect = Wyznacz prostokąt zasięgu światła na ekranie 
if (Shadow mapping włączony i Światło.RzucaCień): 

Rysuj do shadow mapy światła punktowego 
Ustaw Scissor Test 

if (Mapa != nuli i Mapa.Używa_oświetlenia): 
foreach (Fragment in DrawData.MapFragments): 
if (Fragment.AABB przecina zasięg światła): 

Mapa.Rysuj_fragment(Fragment, 

Przebieg światła kierunkowego) 
if (Teren != nuli): 

foreach (Fragment in DrawData.TerrainPatches): 
if (Fragment.AABB przecina zasięg światła): 

Teren.Rysuj_fragment(Fragment, 

Przebieg światła kierunkowego) 
foreach (Fragment in DrawData.OpaąueEntityFragments): 
if (Fragment.Encja używa oświetlenia): 

if (Fragment.Encja.Sfera_otaczająca przecina 
zasięg światła) : 

Rysuj fragment. Przebieg światła kierunkowego 
Wyłącz Scissor Test 

foreach (Światło in DrawData.SpotLights) : 

if (Światło.Aktywne i Światło.Kolor != CZARNY): 

if (Zasięg działania światła przecina zasięg widzenia kamery): 
ScissorRect = Wyznacz prostokąt zasięgu światła na ekranie 
if (Shadow mapping włączony i Światło.RzucaCień): 

Rysuj do shadow mapy światła typu Spot 
Ustaw Scissor Test 

if (Mapa != nuli i Mapa.Używa_oświetlenia): 
foreach (Fragment in DrawData.MapFragments): 
if (Fragment.AABB przecina zasięg światła): 

Mapa.Rysuj_fragment(Fragment, Przebieg światła Spot) 
if (Teren != nuli): 

foreach (Fragment in DrawData.TerrainPatches): 
if (Fragment.AABB przecina zasięg światła): 

Teren.Rysuj_fragment(Fragment, Przebieg światła Spot) 
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foreach (Fragment in DrawData.OpaąueEntityFragments): 
if (Fragment.Encja używa oświetlenia): 

if (Fragment.Encja.Sfera_otaczająca przecina zasięg 
światła): 

Rysuj fragment. Przebieg światła Spot 
Wyłącz Scissor Test 
if (Mgła włączona): 
if (Mapa != nuli): 

foreach (Fragment in DrawData.MapFragments): 

Mapa.Rysuj_fragment(Fragment, Przebieg mgły) 
if (Teren != nuli): 

foreach (Fragment in DrawData.TerrainPatches): 

Teren.Rysuj_fragment(Fragment, Przebieg mgły) 
foreach (Fragment in DrawData.OpaąueEntityFragments): 

Rysuj fragment, Przebieg mgły 

DrawData.TranslucentEntityFragments.Sortuj_wg_odległości_od_kamery 
foreach (Fragment in DrawData.TranslucentEntityFragments): 
if (Fragment oznacza CustomEntity): 

Fragment.Rysuj jako CustomEntity 
else: // Fragment to fragment encji typu MaterialEntity 
if (Fragment.Materiał is WireframeMaterial): 

Fragment.Rysuj jako fragment encji z WireframeMaterial 
else // Fragment.Materiał is TranslucentMaterial 

Fragment.Rysuj jako fragment encji z TranslucentMaterial 
if (Teren != nuli) 

Teren.Rysuj_wodę 
if (Opady != nuli) 

Opady.Rysuj 

Użyta w powyższym kodzie procedura „Rysuj do mapy cienia typu punktowego” 
jest zaimplementowana jako metoda Scene: : DoShadowMapping_Directional. Jej 
zadaniem jest wyznaczenie zasięgu światła w kontekście aktualnej kamery, pobranie 
wszystkich obiektów sceny znajdujących się w tym zasięgu i ich wyrenderowanie do 
mapy cienia za pomocą przeznaczonego w tym celu przebiegu, a także skonstruowa¬ 
nie i zwrócenie macierzy używanych do późniejszego nałożenia mapy cienia podczas 
renderowania obiektów oświetlonym danym światłem. Procedura ta wygląda w pseu- 
dokodzie następująco: 

"function Scene::DoShadowMapping_Directional" 

Frustum = Zbuduj nowy frustum kamery uwzględniający zasięg światła 
if (Mapa != nuli i Mapa.Rzuca_cień): 

MapFragments = Mapa.Fragmenty_widoczne(Frustum) 
if (RunningOptimizer.Sortować_wg_materiału): 

MapFragments.Sortuj_wg_materiału 
Entities = Octree.Encje_rzucające_cień 
foreach (Entity in Entities): 
if (Entity is MaterialEntity): 

foreach (Fragment in Entity.Fragments): 

if (Fragment.Materiał is OpaąueMaterial): 

EntityFragments.Dodaj(Fragment) 
else if (Entity is TreeEntity): 

Trees.Dodaj(Fragment) 
if (Teren != nuli): 

Trees.Dodaj(Teran.Drzewa_rzucające_cień) 
if (RunningOptimizer.Sortować_wg_materiału): 

EntityFragments.Sortuj_wg_materiału 
Trees.Sortuj_wg_gatunku_drzewa 

ViewProj = Oblicz macierz ViewProj światła kierunkowego 

EngineServices.Pobierz mapę cienia 

Dla mapy cienia ustawionej jako cel renderowania: 
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foreach (Fragment in MapFragments): 

Rysuj fragment, Przebieg mapy cienia 
foreach (Fragment in EntityFragments): 

Rysuj fragment, Przebieg mapy cienia 
foreach (Tree in Trees): 

Rysuj Tree, Przebieg mapy cienia 
m2 = Oblicz macierz tranformacji mapy cienia 
Zwróć macierze ViewProj i m2 

Metody wypełniające mapę cienia dla świateł typu punktowego i światła latarki 
wyglądają podobnie. 


Ustawienia renderowania Rysowanie przez silnik każdej porcji geometrii składa się 
z dwóch etapów: 

1. Ustawienie stanów renderowania Direct3D, w tym tekstur, shaderów i parame¬ 
trów przekazanych do shaderów. 

2. Ustawienie aktywnego bufora wierzchołków, bufora indeksów, formatu wierz¬ 
chołka FVF i uruchomienie metody renderującej. 

Ewentualna optymalizacja mogłaby polegać na ustawianiu tylko tych stanów urzą¬ 
dzenia D3D, które zmieniły się od poprzedniego rysowania. Biblioteka Direct3D sa¬ 
modzielnie wykonuje jednak taką optymalizację, dlatego już samo pogrupowanie frag¬ 
mentów przeznaczonych do narysowania wg zbliżonych parametrów (np. ich posorto¬ 
wanie wg używanego materiału) jest pewną optymalizacją. Lepszym rozwiązaniem by¬ 
łoby podzielenie możliwych ustawień na grupy zależnie od częstości zmian (np. usta¬ 
wienia zmieniane tylko raz w każdej klatce, ustawienia zmieniane tylko przy zmianie 
materiału, ustawienia zmieniane dla każdego rysowanego obiektu), ale autor nie zde¬ 
cydował się na użycie tej techniki celem zapewnienia większej prostoty. 

Pierwszy z wyżej wymienionych etapów wykonywany jest przez metodę 
EngineServices : : SetupState_Material (poza przypadkami, kiedy encja sama od- 
rysowuje siebie w niestandardowy sposób — dotyczy to klas pochodnych od 
CustomEntity). Otrzymuje ona wszystkie dane potrzebne do dokonania tych usta¬ 
wień: rodzaj przebiegu, parametry renderowania sceny, obiekt kamery, obiekt ma¬ 
teriału, parametry renderowania encji i obiekt światła. W tym miejscu muszą się 
spotkać parametry wszystkich obiektów biorących udział w renderowaniu (patrz rys. 
3.1) . Karta graficzna nie zna bowiem idei enkapsulacji. W danej chwili ustawiony 
może być tylko jeden aktywny Vertex Shader i Pixel Shader i musi on wykonywać 
wszystkie obliczenia, a przez parametry shaderów muszą być przekazane wszystkie 
dane potrzebne do jego działania. Proces ustawiania składa się z następujących eta¬ 
pów: 

1. Sformułowany zostaje zestaw wartości makr preprocesora dla shadera. 

2. Następuje pobranie shadera o określonych wartościach makr z obiektu shadera 
głównego klasy MainShader, który w razie potrzeby wczytuje go przy pierwszym 
użyciu z dysku bądź kompiluje z kodu źródłowego. 
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Rys. 3.1. Shader jako miejsce, w którym muszą spotkać się parametry wszystkich obiektów 

uczestniczących w procesie renderowania. 


3. Ustawiane są parametry shadera. 

4. Ustawiane są stany Direct3D. 

Rodzaje przebiegów Proces renderowania sceny podzielić można na przebiegi (ang. 
Pass). Rodzaj przebiegu jest podstawowym makrem sterującym kompilacją shadera 
głównego. Shader główny zmienia prawie całą swoją funkcjonalność w zależności od 
typu przebiegu. Oto wykaz rodzajów przebiegów: 

• PASS_BASE = 0 — przebieg bazowy dla fragmentów encji rysowanych materia¬ 
łem nieprzezroczystym. Wykonuje kilka czynności: wypełnia Z-bufor, rysuje po¬ 
wierzchnię oświetloną światłem rozproszonym ( Ambient ), rysuje teksturę emisji 
(Emissive) oraz teksturę mapowania środowiskowego [Enuironmental Map). 

• PASS_FOG = 1 — przebieg nakładający mgłę na fragmenty encji rysowanych ma¬ 
teriałem nieprzezroczystym. 

• PASS_WIREFRAME = 2 — przebieg renderujący w całości fragmenty encji używa¬ 
jące materiału szkieletowego Wiref rameMaterial (łącznie z mgłą). 

• PASS_TRANSLUCENT = 3 — przebieg renderujący w całości fragmenty encji uży¬ 
wające materiału półprzezroczystego TranslucentMaterial (łącznie z mgłą). 

• PASS_DIRECTIONAL = 4 — przebieg dla fragmentów encji rysowanych materia¬ 
łem nieprzezroczystym dodający oświetlenie od światła kierunkowego. 

• PASS_POINT = 5 — przebieg dla fragmentów encji rysowanych materiałem nie¬ 
przezroczystym dodający oświetlenie od światła punktowego. 

• PASS_SPOT = 6 — przebieg dla fragmentów encji rysowanych materiałem nie¬ 
przezroczystym dodający oświetlenie od światła latarki. 

• PASS_SHADOW_MAP = 7 — przebieg renderujący głębokość do mapy cienia. 
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• PAS S_TERRAIN = 8 — przebieg renderujący teren. Rysuje powierzchnię oświe¬ 
tloną światłem rozproszonym ( Ambient ), światłem kierunkowym oraz mgłę. 

Encje rysowane w sposób niestandardowy (CustomEntity), fragmenty encji mate¬ 
riałowych (MaterialEntity) używające materiałów szkieletowych 

(WireFrameMaterial), lub półprzezroczystych (TranslucentMaterial), a także drze¬ 
wa i inne nietypowe elementy sceny są rysowane za jednym razem. Jedynie te frag¬ 
menty encji materiałowych, które używają materiału typu nieprzezroczystego 
(OpaąueMaterial), a także fragmenty terenu, podlegają oświetleniu i ich obraz jest 
budowany w wielu przebiegach. 

W każdym takim przebiegu rysowana jest od nowa geometria danego fragmentu, 
z odpowiednim shaderem i odpowiednimi przekazanymi do niego parametrami. Prze¬ 
bieg bazowy odpowiada za narysowanie wszystkich elementów materiału niezależnych 
od oświetlenia. Następnie osobny przebieg dla każdego światła używa blendingu ad- 
dytywnego, aby rozjaśnić piksele obiektu o oświetlenie danym światłem. Wreszcie, 
przebieg mgły dodaje zamglenie jego obrazu zależnie od odległości. 

Wyróżnienie materiału półprzezroczystego jako osobny i niepodlegający oświetle¬ 
niu było decyzją projektową podyktowaną uproszczeniem organizacji procesu rende- 
rowania sceny. Obiekty półprzezroczyste wymagają do prawidłowego przedstawienia, 
aby renderować je od razu w całości, w kolejności od najdalszych do najbliższych 
względem kamery, ponieważ nie współpracuje z nimi prawidłowo Z-bufor. Tymczasem 
proces renderowania oświetlonej geometrii jest w silniku zorganizowany wg kolejnych 
świateł, nie wg kolejnych obiektów. Zapewnia to większą wydajność oraz pozwala 
na przemian wypełniać i wykorzystywać mapę cienia. Gdyby obiekt półprzezroczysty 
miał podlegać oświetleniu wraz z rzucaniem na niego cienia, musiałyby do jego wy- 
renderowania istnieć i zostać wykorzystane jednocześnie mapy cienia ze wszystkich 
świateł. 

Kolejność wykonywania poszczególnych przebiegów i innych wywołań renderują- 
cych można przedstawić w następujący sposób: 

1. Niebo. 

2. Przebieg bazowy (fragmenty mapy). 

3. Fragmenty terenu. 

4. Przebieg bazowy (fragmenty encji MaterialEntity z materiałem 
OpaąueMaterial). 

5. Drzewa. 

6. Trawa. 

7. Dla kolejnych świateł: a) przebieg wypełniania mapy cienia, b) przebieg światła 
danego typu (fragmenty encji MaterialEntity z materiałem OpaąueMaterial, 
fragmenty mapy, fragmenty terenu). 

8. Przebieg mgły (fragmenty encji MaterialEntity z materiałem OpaąueMaterial, 
fragmenty mapy, fragmenty terenu). 
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9. W kolejności od najdalszych względem kamery: Przebiegi materiałów szkieleto¬ 
wych i półprzezroczystych, encje rysowane we własnym zakresie. 

10. Woda. 

11. Opady atmosferyczne. 


3.2. Implementacja shadera głównego 


Kod źródłowy głównego shadera używanego do renderowania większości rodzajów ele¬ 
mentów w silniku znajduje się w pliku Engine\Multishaders\MainShader . fx. Liczy 
907 linii. Nie jest oczywiście kompilowany w całości. Znajduje się w nim wiele dyrek¬ 
tyw preprocesora dla kompilacji warunkowej #if, na podstawie których wybierane są 
fragmenty przeznaczone do kompilacji shadera z określonym zestawem makr. Jest to 
subtraktywna metoda budowania shaderów (p. 2.4) . Wszystkie używane makra pre¬ 
procesora, ich dopuszczalne wartości, znaczenie i zależności między nimi, jak również 
parametry przekazywane do shadera, ich znaczenie i zależności od makr są opisane 
w pliku doc\Engine\MainShader . txt. 

Plik efektu MainShader. fx to kod w języku HLSL złożony z jednego Vertex Sha¬ 
dera i Pixel Shadera. Uproszczony potok renderowania Direct3D pokazujący przepływ 


danych między nimi znajduje się na rys. 3.2, Wierzchołki z wysłanej do renderowa¬ 
nia siatki trójkątów trafiają wprost do Vertex Shadera. On ma możliwość dokonania 
obliczeń na danych każdego wierzchołka, a wyniki wysyła przez interpolatory do Pixel 
Shadera. Wyniki te są interpolowane między wierzchołkami na powierzchni trójkątów. 
Należą do nich m.in. pozycja i koordynaty tekstury. Tych ostatnich może być wiele, 
dlatego wszelkie niestandardowe dane, które trzeba przekazać do Pixel Shadera, są 
zapisywane jako dodatkowe koordynaty tekstury. Następnie zinterpolowane wartości 
trafiają do Pixel Shadera, który wykonywany jest dla każdego renderowanego piksela. 
Jego zadanie jest na podstawie otrzymanych danych wyliczyć finalny kolor piksela do 
wpisania do celu renderowania (ewentualnie z użyciem blendingu). 



Rys. 3.2. Uproszczony model potoku renderowania Direct3D, pokazujący przepływ danych 
używanych przez Vertex Shader i Pixel Shader. 


Strukturę wierzchołka stanowiącego wejście do Vertex Shadera pokazuje poniższy 
listing. Nie w każdej sytuacji przekazywane czy wykorzystywane są wszystkie z tych 
pól. 

struct VS_INPUT 
f 


float3 Pos : P0SITI0N; 
half3 Normal : NORMAL; 
#if (TERRAIN == 1) 
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half4 TerrainTextureWeights: COLORO; 

#endif 

half BoneWeightO : BLENDWEIGHTO; 
int4 Bonelndices : BLENDINDICESO; 
half2 Tex : TEXCOORDO; 
half3 Tangent : TEXCOORDl; 
half3 Binormal : TEXCOORD2; 

} ; 

• Pos to pozycja wierzchołka we współrzędnych lokalnych modelu. 

• Normal to wektor normalny wierzchołka. 

• TerrainTextureWeights to wagi dla blendingu 4 tekstur wykorzystywanych 
podczas renderowania terenu. 

• BoneWeightO to waga wpływu pierwszej kości na wierzchołek. Waga wpływu 
drugiej kości wynosi 1— BoneWeightO. 

• Bonelndices zawiera indeksy dwóch kości wpływających na wierzchołek (war¬ 
tość 0 oznacza brak kości). 

• Tex to współrzędne tekstury. 

• Tangent i Binormal to wektory styczne do powierzchni. 

Struktura VS_OUTPUT przekazywana z Vertex Shadera do Pixel Shadera jest bar¬ 
dzo złożona. Jej pola są wybierane przez preprocesor zależnie od wartości makr. 
Jest to podyktowane kilkoma przesłankami. Liczba dostępnych interpolatorów jest 
ograniczona. Warto było nadać im nazwy zgodne z przeznaczeniem w danej sytuacji. 
Ponadto w strukturze tej nie powinno być pól nieużywanych, ponieważ kompilacja 
zakończy się błędem w przypadku niewypełnienia któregoś z pól, a ich wypełnianie 
dowolną wartością wymaga dodatkowych instrukcji Vertex Shadera. 

Wyjściem Pixel Shadera jest pojedyncza wartość typu half 4 lub float4 oznacza¬ 
jąca kolor (lub inne dane) przeznaczony do zapisania w aktualnym celu renderowania. 

Obliczenia oświetlenia W przypadku przebiegów nr 4, 5, 6, oznaczających rendero- 
wanie geometrii oświetlonej światłem jednego z trzech rodzajów, do shadera przeka¬ 
zane zostają m.in. następujące makra: 

• PER_PIXEL — wartość 1 mówi, że oświetlenie ma być wykonywane na poziomie 
pikseli, a nie wierzchołków. 

• NORMAL_TEXTURE — wartość 1 mówi, że materiał posiada dodatkową teksturę 
z mapą normalnych. Ta funkcja działa tylko kiedy PER_PIXEL==1. 

• SPOT_SMOOTH —wartość 1 mówi, że światło latarki ma zanikać płynnie od środka 
do krawędzi stożka. 

oraz następujące parametry: 

• CameraPos — pozycja kamery przekształcona do przestrzeni lokalnej obiektu. 

• DirToLight — kierunek „do światła”, czyli zanegowany kierunek padania świa¬ 
tła. 
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• LightPos — pozycja światła przekształcona do przestrzeni lokalnej obiektu. 

• LightRangeSą — kwadrat zasięgu działania światła. 

• LightCosFov2 — cosinus połowy kąta rozchylenia snopa światła latarki. 

• LightCosFov2Factor— współczynniki / (1 - LightCosFov2) . 

• NormalTexture — tekstura z mapą normalnych. 


Na ich podstawie wyliczane są wartości potrzebne do wykonania cieniowania. Na 
poniższych listingach MyDirToLight oznacza znormalizowany wektor kierunku od 
danego wierzchołka do światła w przestrzeni modelu, a Attn to współczynnik [0; 1] 
odpowiedzialny za zanikanie światła wraz z odległością, a w przypadku światła latarki 
dodatkowo wraz z kątem. Dla oświetlenia typu per vertex obliczenia wykonuje Vertex 
Shader: 

half3 MyDirToLight; 
half Attn; 

#if (PASS == 4) // Światło Directional 
MyDirToLight = DirToLight; 

Attn = 1; 

#elif (PASS == 5 || PASS == 6) // Światło Point, Spot 
float3 VecToLight = (float3)LightPos - InputPos; 

MyDirToLight = normalize(VecToLight) ; 

Attn = 1 - min(l, dot(VecToLight, VecToLight) / LightRangeSą); 

#if (PASS == 6) // Światło Spot 

half LightDirDot = max(0, dot(DirToLight, MyDirToLight)); 

#if (SPOT_SMOOTH == 0) 

Attn * = step (LightCosFov2, LightDirDot); 

#else 

Attn *= max(0, (LightDirDot - LightCosFov2) * 

LightCosFov2Factor) ; 

#endif 

#endif 

#endif 

W przypadku oświetlenia typu per pixel, Vertex Shader korzysta z otrzymanych w 
wierzchołku wektorów normalnego i stycznych, aby utworzyć macierz zdolną prze¬ 
kształcać wektory z przestrzeni modelu (ang. Object Space lub Model Space) do prze¬ 
strzeni stycznej (ang. Tangent Space). Następnie używa jej, aby przekształcić do 
przestrzeni stycznej wszystkie wektory biorące udział w oświetleniu i w takiej postaci 
przekazuje je przez interpolatory do Pixel Shadera. Na tym kończy się jego zadanie. 
Podkreślić należy, że przez interpolator przechodzą wektory wraz z długością i dopiero 
w Pixel Shaderze są normalizowane dla otrzymania samego kierunku. Tylko wtedy 
oświetlenie liczone jest prawidłowo. 

float3x3 TangentSpace; 

TangentSpace[0] = InputTangent; 

TangentSpace[1] = InputBinormal; 

TangentSpace[2] = InputNormal; 

#if (PASS == 4) // Światło Directional 

Out.DirToLight = mul(TangentSpace, DirToLight); 

#endif 

#if (PASS == 5 || PASS == 6) // Światło Point, Spot 
float3 VecToLight = LightPos - InputPos; 

Out.YecToLight = mul(TangentSpace, YecToLight); 
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#if (PASS == 6) // Światło Spot 

Out.VecToLight_Model = VecToLight; 

#endif 

#endif 

#if (SPECULAR != 0) 

half3 VecToCam = (float3)CameraPos - InputPos; 

Out.VecToCam = mul(TangentSpace, VecToCam); 

#endif 

Dalej, w przypadku oświetlenia perpbcel, Pixel Shader odbiera zinterpolowane wek¬ 
tory i wykorzystuje je do obliczeń oświetlenia podobnych do przedstawionych wyżej, 
wykonywanych przez Vertex Shader dla oświetlenia per vertex. Ponadto, sampluje 
na początku teksturę mapy normalnych (jeśli jest obecna), aby otrzymać wektor nor¬ 
malny danego miejsca powierzchni 1221 . Wektor ten jest wyrażony w przestrzeni stycz¬ 
nej, tak jak wektory otrzymane od Vertex Shadera. 

half3 Normal; 

#if (NORMAL_TEXTURE == 1) 

Normal = tex2D(NormalSampler, In.Tex)*2-l; 

#else 

Normal = half3(0, 0, 1); 

#endif 

Normal = normalize(Normal); 

half3 MyDirToLight; 
half Attn; 

#if (PASS == 4) // Światło Directional 
MyDirToLight = In.DirToLight; 

Attn = 1; 

#elif (PASS == 5 || PASS == 6) // Światło Point, Spot 
half3 VecToLight = In.VecToLight; 

MyDirToLight = normalize(VecToLight); 

Attn = 1 - saturate(dot(VecToLight, VecToLight) / LightRangeSą); 

#if (PASS == 6) // Światło Spot 

half LightDirDot = dot( 

DirToLight, normalize(In.VecToLight_Model)); 

#if (SPOT_SMOOTH == 0) 

Attn *= step (LightCosFov2, LightDirDot); 

#else 

Attn *= saturate((LightDirDot - LightCosFov2) * 

LightCosFov2Factor); 

#endif 

#endif 

#endif 


Obliczenia cieniowania Dane wyliczone w kodzie z poprzedniego podrozdziału służą 
dalej do obliczeń cieniowania, czyli wpływu światła na powierzchnię z uwzględnieniem 
parametrów materiału. Potrzebne do tego makra to: 

• HALF_LAMBERT — wartość 1 mówi, że do oświetlenia ma zostać użyty wzór Ilalf- 
Lambert IT8l . 

• SPECULAR — wybór rodzaju odblasku. O oznacza brak, 1 oznacza zwykły odblask 
Specular, 2 i 3 to oświetlenie anizotropowe (ang. Anisotropic Lighting). 

• GLOSS_MAP —wartość 1 mówi, że kanał alfa podstawowej tekstury ma oznaczać 
intensywność oblasku. Ta funkcja działa tylko, kiedy SPECULAR! =0. 
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• DIFFUSE_TEXTURE — wartość 1 oznacza, że materiał posiada podstawową tek¬ 
sturę kolom. Jeśli jej nie posiada, rysowany jest jednolitym kolorem. 

• COLOR_MODE — tryb modyfikacji kolom podstawowego przez TeamColor encji. 

Parametry uczestniczące w obliczeniach cieniowania to: 

• DiffuseTexture — podstawowa tekstura koloru. 

• Dif fuseColor —jednolity kolor materiału, używany kiedy nie ma tekstury. 

• TeamColor — kolor zapamiętany dla danej encji. 

• LightColor — kolor światła. 

• SpecularColor — kolor odblasku danego materiału. 

• SpecularPower —wykładnik odblasku. 


Funkcja pomocnicza ProcessTeamColor przetwarza kolor podstawowy materiału, 
odczytany wcześniej z tekstury lub stałej i przekazany jako parametr, uwzględniając 
TeamColor encji i sposób jego wpływu na wygląd powierzchni. 

half4 ProcessTeamColor(half4 DiffuseColor) 

{ 

#if (COLOR_MODE == 1) 

half4 R = DiffuseColor * TeamColor; 

R.a = DiffuseColor.a; 
return R; 

#elif (COLOR_MODE == 2) 

half4 R = lerp(DiffuseColor, TeamColor, DiffuseColor.a) ; 

R.a = DiffuseColor.a; 
return R; 

#else // COLOR_MODE == 0 
return DiffuseColor; 

#endif 

} 


W przypadku oświetlenia per vertex, obliczeń cieniowania dokonuje Vertex Shader. 

half N_dot_L = dot(InputNormal, MyDirToLight); 

#if (HALF_LAMBERT == 1) 

N_dot_L = N_dot_L * 0.5 + 0.5; 

#endif 

half Diffuse = N_dot_L * Attn; 

Out.Diffuse = Diffuse * LightColor; 

#if (SPECULAR != 0) 

half3 MyDirToCam = normalize(CameraPos - InputPos); 
half3 Half = normalize(MyDirToLight + MyDirToCam); 
half N_dot_H = dot(InputNormal, Half); 
half Specular = pow(N_dot_H, SpecularPower); 

Out.Specular = Specular * LightColor * Diffuse * SpecularColor; 
#endif 

Dwie wartości wyliczane przez ten kod to kolor oświetlenia rozproszonego Diffuse 
i kolor odblasku Specular. Ten pierwszy powstaje zgodnie z prawem Lamberta. Mówi 
ono, że intensywność światła rozproszonego padającego na powierzchnię jest wprost 
proporcjonalne do cosinusa kąta 6 między kierunkiem do źródła światła, a wektorem 
normalnym do powierzchni w danym miejscu. Ten kąt z kolei jest równy iloczynowi 
skalarnemu tych dwóch wektorów. W powyższym kodzie odpowiada mu zmienna 
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Rys. 3.3. Oświetlenie Diffuse: a) standardowe, b) HalJ-Lambert. 


N_dot_L. Dodatkowa modyfikacja oświetlenia to Half-Lambert 1181 pokazany na rys. 

EDU 

Druga wartość to odblask Specular, wyliczany metodą Blinna U51 . W oryginalnej 
metodzie Phonga 1141 brany jest kąt między wektorem światła odbitym od powierzchni 
a wektorem do kamery, podniesiony do potęgi. Metoda Blinna wymaga mniej obliczeń 
przybliżając ten wynik poprzez podniesienie do potęgi kąta między wektorem normal¬ 
nym a tzw. wektorem połówkowym Half, który powstaje przez uśrednienie wektora 
do światła i wektora do kamery. 

Pixel Shader sampluje jedynie teksturę podstawową koloru i łączy ją z tymi dwoma 
kolorami oświetlenia wyliczonymi przez Vertex Shader, zwracając wynik końcowy. 

Out = DiffuseTextureColor * In.Diffuse; 

#if (SPECULAR != 0) 

#if (GLOSS_MAP == 1) 

Out += In.Specular * DiffuseTextureColor.a; 

#else 

Out += In.Specular; 

#endif 

#endif 

W przypadku oświetlenia per pixel, podobne obliczenia wykonuje w całości Pixel 
Shader. Są jednak między nimi dwie istotne różnice. Po pierwsze, wszystkie obliczenia 
są wykonywane w przestrzeni stycznej, a nie w przestrzeni modelu. Po drugie, wektor 
normalny pobierany jest z tekstury mapy normalnych, a nie wprost z wierzchołka. 

half N_dot_L = dot(Normal, MyDirToLight); 

#if (HALF_LAMBERT == 1) 

N_dot_L = N_dot_L * 0.5 + 0.5; 

#endif 

half Diffuse = N_dot_L * Attn; 

#if (NORMAL_TEXTURE == 1 && HALF_LAMBERT == 0) 
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Diffuse *= (dot(half3(O,O,1), MyDirToLight) >= 0); 

#endif 

half4 OutDiffuse = Diffuse * LightColor; 

half4 OutSpecular; 

#if (SPECULAR != 0) 

float3 DirToCam = normalize(In.VecToCam); 
half N_dot_H; 

#if (SPECULAR == 1) // Zwykły odblask 

half3 Half = normalize(MyDirToLight + DirToCam); 

N_dot_H = dot(Normal, Half); 

#elif (SPECULAR == 2) // Anisotropic Lighting po Tangent 
half LdotT = MyDirToLight.x; 
half VdotT = DirToCam.x; 

N_dot_H = sqrt(l - LdotT*LdotT) * sqrt(l - VdotT*VdotT) - 
LdotT*VdotT; 

#else // (SPECULAR == 3) // Anisotropic Lighting po Binormal 
half LdotT = MyDirToLight.y; 
half VdotT = DirToCam.y; 

N_dot_H = sqrt(l - LdotT*LdotT) * sqrt(l - VdotT*VdotT) - 
LdotT*VdotT; 

#endif 

half Specular = pow(N_dot_H, SpecularPower); 

OutSpecular = Specular * LightColor * Diffuse * SpecularColor; 
#endif 

Out = DiffuseTextureColor * OutDiffuse; 

#if (SPECULAR != 0) 

#if (GLOSS_MAP == 1) 

Out += OutSpecular * DiffuseTextureColor.a; 

#else 

Out += OutSpecular; 

#endif 

#endif 

Na uwagę w powyższym kodzie zasługują obliczenia oświetlenia anizotropowego. 
Może ono działać tylko kiedy oświetlenie jest per pixel, ale nie ma mapy normalnych. 
Współczynnik odblasku jest wtedy wyliczany w inny sposób niż wg opisanego wyżej 
wzoru Blinna i aproksymuje oświetlenie materiału o mikrostrukturze złożonej z włó¬ 
kien (np. tkanina, włosy, polerowany metal) ułożonych wzdłuż wektorów stycznych 
siatki — do wyboru Tangent lub Binormal. Wzory te zostały wyprowadzone na pod¬ 
stawie □Mol. 


Obliczenia cienia Rzucanie cienia zostało w silniku zrealizowane za pomocą tech¬ 
niki mapy cienia, znanej jako Shadow Mapping. Do mechanizmu cieni shader główny 
używa następujących makr: 

• SHADOW_MAP_MODE to sposób zapisywania wartości do mapy cienia (p. niżej). 

• VARIABLE_SHADOW_FACTOR równy 1 oznacza, że stopień przyciemnienia geome¬ 
trii w cieniu nie jest stały, ale maleje wraz z odległością. 

• POINT_SHADOW_MAP równy 1 oznacza, że rysowany jest cień dla światła punkto¬ 
wego, w którym wykorzystywana jest sześcienna tekstura mapy cienia. 

oraz następujących parametrów: 

• ShadowFactor to współczynnik jasności geometrii znajdującej się w cieniu. 
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• ShadowFactorA, ShadowFactorB to współczynniki funkcji liniowej opisującej za¬ 
nikanie powyższego współczynnika jasności wraz z odległością od kamery. 

• ShadowMapTexture to tekstura mapy cienia. 

• ShadowMapMatrix to macierz przekształcająca punkty do współrzędnych mapy 
cienia. 

• ShadowMapSize i ShadowMapSizeRcp to rozmiar i odwrotność rozmiaru mapy 
cienia, w pikselach. 

• ShadowEpsilon to wartość tolerancji zapobiegająca artefaktom wynikającym ze 
skończonej dokładności i rozdzielczości mapy cienia. 

• LightRangeSq_World to zasięg światła punktowego w przestrzeni świata. 

Technika mapy cieni składa się z dwóch etapów. W pierwszym etapie osobny prze¬ 
bieg renderuje całą geometrię do tekstury mapy cienia, gdzie jako kolory pikseli zako¬ 
dowane zostają odległości/głębokości od źródła światła do najbliższej geometrii. 

W przypadku świateł punktowych używana jest tekstura sześcienna i zapisywana 
jest w niej odległość od pozycji światła do punktu. W przypadku pozostałych ty¬ 
pów świateł dokonywane jest przekształcenie wraz z rzutowaniem perspektywicznym, 
które sprowadza geometrię do przestrzeni światła (ang. Light Space) i zapisywana jest 
głębokość, tak jak w Z-buforze. Ponieważ ze względu na sposób działania interpola¬ 
cji danych przekazywanych od Vertex Shadera do Pixel Shadera nie można przekazać 
tam wprost odległości ani głębokości, przekazywane są inne dane. W przypadku świa¬ 
tła punktowego jest to wektor od punktu do światła, z którego Pixel Shader wylicza 
długość. W przypadku innych typów świateł są to komponenty {z, w) pozycji wierz¬ 
chołków po transformacji we współrzędnych jednorodnych, a Pixel Shader dokonuje 
dzielenia z/w. 

Oto fragment kodu Vertex Shadera używany w przebiegu renderowania do mapy 
cienia: 

#if (POINT_SHADOW_MAP == 1) 

Out.VecToLight = InputPos - LightPos; 

#else 

Out.ShadowMapZW = Out.Pos.zw; 

#endif 

#if (ALPHA_TESTING == 1) 

#if (TEXTURE_ANIMATION == 1) 

Out.Tex = mul(float4(In.Tex, 0, 1), (float4x2)TextureMatrix); 

#else 

Out.Tex = In.Tex; 

#endif 

#endif 

Na uwagę zasługuje fakt, że choć w omawianym przebiegu nie są potrzebne kolory, 
koordynaty tekstury muszą zostać przekazane, a tekstura podstawowa samplowana 
w Pixel Shaderze w przypadku kiedy materiał stosuje test Alfa. Wówczas bowiem 
kanał Alfa tekstury podstawowej wyznacza miejsca przezroczyste. 

Oto kod Pixel Shadera używany w przebiegu renderowania do mapy cienia: 
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#if (P OINT_S HAD OW_MAP == 1) 

float v = dot(In.VecToLight, In.VecToLight) / LightRangeSą; 

#else 

float v = In.ShadowMapZW.x / In.ShadowMapZW.y; // z/w 
#endif 

#if (SHADOW_MAP_MODE == 1) // Wykorzystaj składową R 

Out = float4 (v, v, v, v) ; 

#elif (SHADOW_MAP_MODE == 2) // Spakuj do składowych RGB 

Out = v * float4 ( 256*256, 256, 1, 0 ); 

Out = frac (Out); 

#endif 

#if (ALPHA_TESTING == 1 && SHADOW_MAP_MODE == 1) 
float4 DiffuseTextureColor; 

#if (DIFFUSE_TEXTURE == 1) 

DiffuseTextureColor = tex2D(DiffuseSampler, In.Tex); 

#else 

DiffuseTextureColor = DiffuseColor; 

#endif 

Out.a = DiffuseTextureColor.a; 

#endif 

Omówienie techniki mapy cieni nie leży w zakresie tej pracy. Na uwagę zasługuje 
natomiast sposób zapisywania wartości odległości/głębokości do mapy cienia. War¬ 
tość ta, podzielona przez maksimum dla sprowadzenia do zakresu 0 ... 1, musi zostać 
wpisana do tekstury jak kolor piksela. Jej wpisanie do jednej ze składowych ARGB 
zwyczajnej tekstury nie wchodzi jednak w grę, ponieważ precyzja 8 bitów na kompo¬ 
nent jest niewystarczająca. Najlepszym wyjściem jest w takiej sytuacji użycie tekstury 
w formacie o zwiększonej precyzji i liczbie kanałów ograniczonej do 1 lub 2, takich 
jak D3DFMT_R32F albo D3DFMT_G16R16. Konfiguracji takiej odpowiada wartość makra 
S HAD 0W_MAP_MOD E=1. 

Niektóre z takich formatów są niestety niedostępne do wykorzystania jako cel ren- 
derowania na niektórych modelach kart graficznych, na których silnik powinien z 
założenia działać prawidłowo (np. GeForce FX 5200). Dlatego wprowadzone zostało 
dodatkowe rozwiązanie, bardziej kosztowe obliczeniowo ale bardziej kompatybilne, 
któremu odpowiada wartość makra SHAD0W_MAP_M0DE=2. Polega ono na spakowaniu 
wartości odległości/głębokości do 3 składowych tekstury (RGB) i pozwala na wykorzy¬ 
stanie standardowej tekstury w formacie D3DFMT_A8R8G8B8. 

Drugi etap polega na wykorzystaniu tekstury mapy cienia podczas renderowania 
geometrii oświetlonej danym światłem do stwierdzenia, czy dane miejsce jest zasło¬ 
nięte (jest w cieniu). Czynność tą wykonuje funkcja SampleShadowMap: 

half SampleShadowMap(VS_0UTPUT In) 

{ 

const float4 RGBA_Factors = float4 (1/256/256, 1/256, 1, 0); 

#if (PASS == 5) // Światło Point - Cube Map 
float3 VecFromLight = In.VecFromLight_World; 
float DistFromLight = dot(VecFromLight, VecFromLight); 
float3 ShadowTexC = VecFromLight; 
float4 samples; 

ShadowTexC = normalize(ShadowTexC) ; 

float3 lerps = frac(ShadowTexC * ShadowMapSize); 

#if (SHADOW_MAP_MODE == 1) // Składowa R 
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samples.x = texCUBE(ShadowMapSampler, ShadowTexC + 
float3 (0, 0, 0)); 

samples.y = texCUBE(ShadowMapSampler, ShadowTexC + 
float3(ShadowMapSizeRcp, ShadowMapSizeRcp, 0)); 
samples.z = texCUBE(ShadowMapSampler, ShadowTexC + 
float3(ShadowMapSizeRcp, 0, ShadowMapSizeRcp)); 
samples.w = texCUBE(ShadowMapSampler, ShadowTexC + 
float3(0, ShadowMapSizeRcp, ShadowMapSizeRcp)); 

#elif (SHADOW_MAP_MODE == 2) // Składowe RGB 

samples.x = dot(RGBA_Factors, texCUBE(ShadowMapSampler, 

ShadowTexC + float3(0, 0, 0))); 
samples.y = dot(RGBA_Factors, texCUBE(ShadowMapSampler, 

ShadowTexC + float3(ShadowMapSizeRcp, ShadowMapSizeRcp, 0) ) ) ; 
samples.z = dot(RGBA_Factors, texCUBE(ShadowMapSampler, 

ShadowTexC + float3(ShadowMapSizeRcp, 0, ShadowMapSizeRcp))); 
samples.w = dot(RGBA_Factors, texCUBE(ShadowMapSampler, 

ShadowTexC + float3(0, ShadowMapSizeRcp, ShadowMapSizeRcp))); 
#endif 

half4 compared_samples = 

(DistFromLight / LightRangeSq_World) < (samples + ShadowEpsilon); 
return (compared_samples.x + compared_samples.y + 
compared_samples.z + compared_samples.w) / 4; 

#else // Światło inne - zwykła tekstura 

float4 ShadowMapPos = saturate(In.ShadowMapPos / In.ShadowMapPos.w); 
float2 texelpos = ShadowMapPos.xy * ShadowMapSize; 
float2 lerps = frac(texelpos); 
float4 samples; 

#if (SHADOW_MAP_MODE == 1) // Składowa R 

samples.x = tex2D(ShadowMapSampler, ShadowMapPos.xy).r; 
samples.y = tex2D(ShadowMapSampler, ShadowMapPos.xy + 
half2 (ShadowMapSizeRcp, 0 )).r; 

samples.z = tex2D(ShadowMapSampler, ShadowMapPos.xy + 
half2 (0, ShadowMapSizeRcp)) . r; 

samples.w = tex2D(ShadowMapSampler, ShadowMapPos.xy + 
half2 (ShadowMapSizeRcp, ShadowMapSizeRcp)) .r; 

#elif (SHADOW_MAP_MODE == 2) // Składowe RGB 

samples.x = dot(RGBA_Factors, tex2D(ShadowMapSampler, 

ShadowMapPos.xy)); 

samples.y = dot(RGBA_Factors, tex2D(ShadowMapSampler, 

ShadowMapPos.xy + half2(ShadowMapSizeRcp, 0 ))); 

samples.z = dot(RGBA_Factors, tex2D(ShadowMapSampler, 

ShadowMapPos.xy + half2(0, ShadowMapSizeRcp))); 

samples.w = dot(RGBA_Factors, tex2D(ShadowMapSampler, 

ShadowMapPos.xy + half2(ShadowMapSizeRcp, ShadowMapSizeRcp))); 
#endif 

float4 compared_samples = (ShadowMapPos.zzzz <= samples); 
return lerp( 

lerp(compared_samples.x, compared_samples.y, lerps.x), 
lerp(compared_samples.z, compared_samples.w, lerps.x), 
lerps.y).r; 

#endif 

} 


Powyższa funkcja wykonuje filtrowanie próbek pobranych z mapy cienia. Nie 
można rozwiązać tego za pomocą standardowego filtrowania tekstur, jakie oferuje 
sprzęt graficzny, ponieważ interpolacja wartości zapisanych w mapie cienia nie ma 
sensu. Interpolacja musi nastąpić po wykonaniu porównania pobranej wartości z war¬ 
tością odniesienia. Autor użył tutaj, ze względu na wydajność, najprostszego sposobu 
wygładzania cieni — PCF (ang. Percentage Closer Filtering) dla 4 próbek 1301 . Wsparcie 
sprzętowe dla takiego PCF istnieje, ale jest obecne tylko na kartach graficznych firmy 
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NVIDIA jako niestandardowe rozszerzenie i dlatego nie zostało wykorzystane I3U . 

Na uwagę zasługuje trudność w filtrowaniu sześciennej tekstury mapy cienia, wy¬ 
korzystywanej dla świateł punktowych. Użyty został w tym celu autorski pomysł na 
modyfikowanie wektora 3D używanego do adresowania takiej tekstury w sposób przy¬ 
pominający wybór 4 spośród 8 wierzchołków sześcianu o wielkości 1 teksela, jak to 
pokazuje rys. 3.4[ Otrzymany w ten sposób efekt nie jest bardzo dobry, ale jest lepszy 
niż całkowity brak filtrowania, kiedy to teksele mapy cienia są widoczne jako ostre 
„schodki” wyznaczające krawędź cienia. 



Rys. 3.4. Sposób adresowania tekstury sześciennej mapy cienia podczas próbkowania dla 

PCF. 


Wzmianka należy się też problemowi przezroczystości. Obiekty półprzezroczyste 
nie podlegają w opisanym silniku oświetleniu, a więc także nie rzucają cienia. Obiekty 
wykorzystujące test Alfa mogą jednak to robić, co jest bardzo istotne podczas ryso¬ 
wania drzew, trawy i innych obiektów tego rodzaju. Tymczasem, zależnie od karty 
graficznej, test alfa nie zawsze działa w przypadku tekstur o formatach takich jak 
D3DFMT_R32F. Rozwiązanie tego problemu mogłoby polegać na „ręcznym” wykonaniu 
tego testu poprzez anulowanie rysowania pikseli w Pixel Shaderze instrukcją texkill, 
której odpowiada funkcja HLSL clip. 


Obliczenia mgły W grafice 3D czasu rzeczywistego najczęściej stosowana jest mgła, 
której intensywność wzrasta wraz z odległością/głębokością liniowo lub wykładniczo. 
W opisywanym silniku zaimplementowana jest tylko mgła liniowa. Jej jedynym pa¬ 
rametrem, oprócz koloru, jest procent odległości, w której się zaczyna. Kończy się 
zawsze na końcu zasięgu kamery ( Z-Far ). 

Parametry dla shadera głównego biorące udział w renderowaniu mgły to: 

• FogColor — kolor mgły, 

• FogFactors — wyliczone przez CPU współczynniki równania liniowego do inten¬ 
sywności mgły w funkcji z = [0; 1], 

W przypadku renderowania z użyciem materiału półprzezroczystego, kiedy koń¬ 
cowy obraz powstaje w pojedynczym przebiegu, obliczenia mgły są wplecione w pozo¬ 
stałe obliczenia cieniowania. Jeśli natomiast obiekt rysowany jest materiałem nieprze- 
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zroczystym, po narysowaniu jego obrazu będącego sumą przebiegów dla poszczegól¬ 
nych świateł następuje osobny przebieg mgły (PASS=1), wykorzystujący alfa-blending. 
Oto fragment Vertex Shadera dla tego przebiegu: 

Out.Fog = FogColor; 

Out.Fog.a = FogFactors.x * Out.Pos.z + FogFactors.y; 

Pixel Shader przepisuje tylko na wyjście zinterpolowany kolor mgły wraz z kanałem 
alfa. 

Obliczenia animacji tekstury Koordynaty tekstury mogą być modyfikowane przez 
dodatkową macierz pamiętaną w encji, co pozwala na animowanie (np. przewija¬ 
nie) tekstury na powierzchni modelu. Aby uzyskać ten efekt, shader główny otrzy¬ 
muje makro TEXTURE_ANIMATI0N=1 oraz macierz tekstury przekazaną w parametrze 
TextureMatrix. Kod Vertex Shadera przekształcający koordynaty tekstury wygląda 
następująco: 

#if (TEXTURE_ANIMATION == 1) 

Out.Tex = mul (float4(In.Tex, 0, 1), (float4x2)TextureMatrix); 

#else 

Out.Tex = In.Tex; 

#endif 

Obliczenia przebiegu bazowego Wszystkie fragmenty geometrii, które używają ren- 
derowania wieloprzebiegowego, są najpierw renderowane przebiegiem bazowym 
(PASS=0). Wykonuje on kilka czynności. Jedną z nich jest zapis głębokości do Z- 
bufora. Następne przebiegi wykonują już tylko test Z, bez zapisywania do Z-bufora. 
Ciekawą optymalizacją jest też wykonywanie testu Alfa tylko w przebiegu bazowym, 
by w następnych przezroczyste piksele były odrzucane przez test Z dzięki ustawieniu 
dla takich przypadków funkcji porównującej testu Z na D3DCMP_EQUAL. 

Niektóre źródła postulują wypełnianie Z-bufora w osobnym przebiegu z wyłączo¬ 
nym zapisem pikseli do celu renderowania, co ma przyspieszać renderowanie dwu¬ 
krotnie. W omawianym silniku są jednak efekty, które muszą być wyrenderowane 
jako „bazowe”, więc rozdzielenie ich rysowania od wypełnienia Z-bufora kosztowa¬ 
łoby dodatkowy przebieg, a więc konieczność dodatkowego rysowania całej widocznej 
geometrii sceny, co zdaniem autora mogłoby zniweczyć potencjalne korzyści wydajno¬ 
ściowe tej sztuczki. 

Pierwszym z efektów renderowanych do celu renderowania przez przebieg bazowy 
jest normalny kolor/tekstura potraktowana jako oświetlenie otoczenia (ang. Ambient), 
czyli bez wpływu konkretnego światła. Makro AMBIENT_MODE może przyjmować warto¬ 
ści: O oznaczająca brak oświetlenia otoczenia (kolor jest czarny), 1 oznaczająca pełne 
oświetlenie otoczenia (stosowane kiedy dany fragment nie podlega oświetleniu lub 
oświetlenie w silniku jest całkowicie wyłączone), 2 oznaczająca mnożenie koloru pod¬ 
stawowego przez kolor i intensywność oświetlenia otoczenia. Odpowiedni kod Pixel 
Shadera to: 
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float4 MyDiffuseColor; 

#if (AMBIENT_MODE == 0) 

MyDiffuseColor = half4 (0, 0, 0, 1); 

#if (ALPHA_TESTING == 1) 

MyDiffuseColor.a = tex2D(DiffuseSampler, In.Tex).a; 

#endif 

Out = MyDiffuseColor; 

#else 

#if (DIFFUSE_TEXTURE == 1) 

MyDiffuseColor = tex2D(DiffuseSampler, In.Tex); 

#else 

MyDiffuseColor = DiffuseColor; 

#endif 

Out = ProcessTeamColor(MyDiffuseColor) ; 

#endif 

#if (AMBIENT_MODE == 2) 

Out *= AmbientColor; 

#endif 

Drugim efektem przebiegu bazowego jest nakładanie dodatkowej tekstury „emisji” 
(ang. Emissive). Jest to tekstura nie podlegająca oświetleniu, na której zaznaczone 
są miejsca mające wyglądać jakby same świeciły, np. diody na panelu komputera 
czy innej maszyny. Włączeniem efektu Emissive steruje makro EMISSIVE, a tekstura 
emisji jest przekazana przez parametr EmissiveTexture. 

#if (EMISSIVE == 1) 

Out += tex2D(EmissiveSampler, In.Tex); 

#endif 

Kolejnym efektem jest mapowanie środowiskowe (ang. Enwironmental Mapping). 
Połga ono na teksturowaniu obiektu mapą sześcienną za pomocą wektora kamery 
odbitego od powierzchni obiektu. Jeśliby na przykład wyrenderować do takiej mapy 
sześciennej obraz sceny z pozycji obiektu i nałożyć ją na ten obiekt, to zastosowanie 
mapowania środowiskowego sprawi, że będzie on wyglądał jak wykonany z metalu 
odbijającego światło. Ponadto nałożenie specjalnie przygotowanych tekstur pozwala 
uzyskać wiele ciekawych efektów. Włączeniem tego efektu steruje makro 
ENVIRONMENTAL_MAPP ING, a używana do niego tekstura sześcienna przekazywana jest 
przez parametr 

EnvironmentalTexture. Odpowiedni kod to: 

////// VERTEX SHADER 

#if (ENVIRONMENTAL_MAP PING == 1) 

float3 VecFromCam = (float3)InputPos - CameraPos; 
float3 Reflected = reflect(VecFromCam, InputNormal); 

Out.ReflectedErwDir = Reflected; 

#endif 

////// PIXEL SHADER 
#if (ENVIRONMENTAL_MAPPING == 1) 
float4 EnvSample = texCUBE ( 

EnvironmentalSampler, In.ReflectedEnvDir); 

Out += EnvSample * EnvSample.a; 

#endif 

Ostatnim z efektów przebiegu bazowego jest Fresnel Term. Wyliczany jest on rów¬ 
nież, podobnie jak pozostałe efekty opisane tutaj, niezależnie od oświetlenia konkret¬ 
nym światłem. Polega na „podświetleniu” obiektu jakby od tyłu dodając określony 
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kolor tym intensywniej, im bardziej dane miejsce powierzchni jest równoległe do kie¬ 
runku kamery. Implementacja działająca także dla obiektów dwustronnych i półprze¬ 
zroczystych pozwala uzyskać ciekawe efekty, jak widać na rys. 3.5[ Włączeniem tej 
techniki steruje makro FRESNEL_TERM. Przekazywane w związku z nią parametry to 
FresnelColor (kolor) i FresnelPower (wykładnik potęgi). Oto odpowiedni kod głów¬ 
nego shadera: 



Rys. 3.5. Przykład zastosowania efektu Fresnel Term wraz z materiałem dwustronnym 
półprzezroczystym do otrzymania wyglądu „ducha”. 


half4 CalcFresnel (float3 VertexPos, float3 VertexNormal) 

{ 

float3 DirToCam = normalize(CameraPos - VertexPos); 

float Dot = dot(DirToCam, VertexNormal); 

return FresnelColor * pow(l - abs (Dot), FresnelPower); 

} 

////// VERTEX SHADER 
#if (FRESNEL_TERM == 1) 

Out.Fresnel = CalcFresnel(InputPos, InputNormal); 
#endif 

////// PIXEL SHADER 
#if (FRESNEL_TERM == 1) 

Out += In.Fresnel; 

#endif 


3.3. Format pliku modeli 3D 

Kształ modeli 3D, mapowanie tekstury i animacje tworzyć trzeba w odpowiednim pro¬ 
gramie graficznym, np. Blender, 3ds Max, Maya. Powstaje problem z formatem pliku, 
w którym taki model wczytywany powinien być przez silnik. Istnieje wiele popularnych 
formatów (np. OBJ, 3DS, MD2, MD5), ale każdy z nich zależnie od potrzeb okazać 
się może niewystarczający lub po prostu nieodpowiedni. Istnieje też format mający 
ustandardyzować wymianę danych graficznych 3D między programami — COLLADA. 
Niestety jest to format bardzo skomplikowany i oparty na XML-u. Dlatego częstą 
praktyką jest projektowanie własnych formatów plików modeli i pisanie wtyczek dla 
programów graficznych 3D, eksportujących modele do takiego formatu. 
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Tak też postąpił autor projektując format nazwany QMSH (od The Finał Quest 
Mesh). Odpowiednia wtyczka do programu Blender eksportuje model do tekstowego 
formatu pośredniego QMSH.TMP, a konsolowe narzędzie Tools przetwarza go na for¬ 
mat docelowy QMSH. Jest to format binarny zaprojektowany tak, aby tablicę wierz¬ 
chołków i indeksów można było wczytać wprost do buforów Direct3D, bez żadnego 
przetwarzania. 

Nagłówek pliku składa się z następujących pól: 

• identyfikator formatu — 6 znaków "TFQMSH", 

• identyfikator wersji — 2 znaki "10", 

• dlagi — 1 bajt, w którym: ustawiony bit 0x01 oznacza, że wierzchołki posiadają 
wektory styczne Tangent i Binormal, ustawiony bit 0x02 oznacza, że obecny jest 
szkielet, animacje, a wierzchołki posiadają informację o wpływie kości, 

• liczba wierzchołków — typu uint2, 

• liczba trójkątów — typu uint2, 

• liczba pod-siatek — typu uint2, 

• liczba kości — typu uint2, 

• liczba animacji — typu uint2, 

• promień sfery otaczającej siatkę, której środek leży w punkcie (0,0,0) — typu 
f loat, 

• minimalne i maksymalne współrzędne prostopadłościanu otaczającego siatkę 
(xi,yi,zi),(x 2 ,y 2 ,Z 2 ) — 6 liczb typu float, 

• offset od początku pliku do początku bufora wierzchołków — typu uint4, 

• offset od początku pliku do początku bufora indeksów — typu uint4, 

• offset od początku pliku do początku danych o pod-siatkach — typu uint4, 

• offset od początku pliku do początku danych kości — typu u±nt4 (0 jeśli brak), 

• offset od początku pliku do początku danych animacji — typu uint4 (0 jeśli 
brak). 

Bufor wierzchołków rozpoczyna się bajtem kontrolnym o wartości 0. Każdy wierz¬ 
chołek składa się z pól: 

• pozycja (x, y, z) — 3 liczby typu float, 

• informacje o wypływie kości, obecne tylko jeśli ustawiona jest odpowiednia flaga 
w nagłówku: 

- waga wpływu na dany wierzchołek pierwszej z dwóch kości — liczba typu 
float w zakresie [0; 1], Waga wpływu drugiej kości jest wyliczana automa¬ 
tycznie i wynosi W 2 = I — wi, 

- liczba 32-bitowa bez znaku, której najmłodszy bajt przechowuje indeks pierw¬ 
szej kości wpływającej na ten wierzchołek, a drugi z kolei bajt — indeks 
drugiej kości, 

• wektor normalny (x, y, z) — 3 liczby typu float. Jest zawsze znormalizowany. 
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• koordynaty tekstury (t x ,t y ) — 2 liczby typu float, 

• wektory styczne, obecne tylko jeśli ustawiona jest odpowiednia flaga w nagłówku. 

(xt,y t ,zt),(x b ,y b ,z b ) — 6 liczb typu float. 


Bufor indeksów rozpoczyna się bajtem kontrolnym o wartości 0. Każdemu trójką¬ 
towi odpowiadają w nim 3 indeksy wierzchołków. Każdy indeks to liczba typu uint2. 

Tablica informacji o pod-siatkach rozpoczyna się bajtem kontrolnym o wartości 0. 
Każda pod-siatka jest opisana następującą strukturą: 

• numer pierwszego trójkąta pod-siatki — typu uint2, 

• liczba trójkątów pod-siatki — typu uint2, 

• najniższy indeks używanego przez pod-siatkę wierzchołka — typu uint2, 

• liczba wierzchołków, która razem z poprzednim polem wyznacza zakres wierz¬ 
chołków używanych przez pod-siatkę — typu uint2, 

• nazwa pod-siatki — 1 bajt długości + znaki ASCII, 

• nazwa materiału — 1 bajt długości + znaki ASCII. 

Tablica kości rozpoczyna się bajtem kontrolnym o wartości 0. Każda kość jest 
opisana następującą strukturą: 

• indeks kości nadrzędnej — typu uint2. Kości indeksowane są od 1, warość 0 
oznacza brak kości, 

• macierz kości 4x3 przekształcająca współrzędne z układu lokalnego tej kości do 
układu kości nadrzędnej (lub układu modelu, jeśli to kość pierwszego poziomu), 
zapisana kolejnymi wierszami — 12 liczb typu float, 

• nazwa kości — 1 bajt długości + znaki ASCII. 

Tablica animacji rozpoczyna się bajtem kontrolnym o wartości 0. Każda animacja 
jest opisana następującą strukturą: 

• nazwa animacji — 1 bajt długości + znaki ASCII, 

• długość animacji — liczba typu float, w sekundach, 

• liczba klatek kluczowych — typu uint2, 

• tablica klatek kluczowych, a każda posiada pola: 

- czas — typu float, 

- tablica przekształceń. Przekształcenie dla każdej kości posiada pola: 

* translacja — wektor (x, y,z ), 3 liczby typu float, 

* rotacja — kwaternion ( x, y , z, w), 4 liczby typu float, 

* skalowanie —jedna liczba typu float. 
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3.4. Implementacja animacji szkieletowej 


Animacja szkieletowa polega na deformacji siatki modelu. Wierzchołki (ich pozy¬ 
cja, jak i wektory normalne oraz styczne) są przekształcane przez „kości”. Kość nie 
jest żadnym widocznym obiektem, a jedynie abstrakcyjnym pojęciem reprezentującym 
określone dane matematyczne. Dzięki nim całe grupy wierzchołków (np. wszelka geo¬ 
metria przedstawiająca rękę) może się poruszać sterowana pojedynczym przekształ¬ 
ceniem opisującym kość tej ręki, przesuwając, skalując oraz przede wszystkim obra¬ 
cając się wokół punktu początkowego danej kości. Kości tworzą hierarchię, tak że ich 
przekształcenia są składane. Przykładowo, część siatki sterowana przez kość dłoni 
porusza się też razem z całym ramieniem. 

Skinning to technika, w której na wierzchołek może wypływać więcej niż jedna 
kość. Wektory takiego wierzchołka są wówczas przekształcane przez macierze wszyst¬ 
kich kości, które na niego wpływają, a następnie interpolowane stosownie do wag 
wpływu tych kości. Wierzchołek musi więc mieć zapisane indeksy kości, które na 
niego wpływają oraz wagi wpływu tych kości. Autor zdecydował się na umożliwienie 
wypływu 2 kości na wierzchołek. 

Obliczenia animacji szkieletowej składają się z trzech etapów. Pierwszy etap jest 
wykonywany tylko raz, podczas pierwszego zapytania. Wylicza on tablicę macierzy, 
które dla każdej kości opisują przekształcenie ze współrzędnych modelu do współ¬ 
rzędnych tej kości. Obliczenia te realizuje metoda GetModelToBoneMatrices klasy 
res : : QMesh, a algorytm w pseudokodzie wygląda następująco: 

ModelToBoneMatrices = MATRIX[] 

ModelToBoneMatrices[0] = IDENTITY 
foreach (Kość in Kości modelu): 

ModelToBoneMatrices[Kość] = Odwrotność macierzy (Kość.Macierz) 

if (Kość nie jest pierwszego poziomu): 

ModelToBoneMatrices[Kość] = 

ModelToBoneMatrices[Kość.Kość_nadrzędna] * 

ModelToBoneMatrices[Kość] 
return ModelToBoneMatrices 

Drugi etap polega na wyliczeniu tablicy tzw. macierzy kości. Wykonuje go me¬ 
toda GetBoneMatrices klasy res : :QMesh. Dla każdej kości powstaje macierz, która 
reprezentuje przekształcenie wierzchołków z ich pozycji spoczynkowej w przestrzeni 
lokalnej modelu do pozycji ustalonej przez daną animację, również w przestrzeni mo¬ 
delu. Ponieważ zbudowanie tych macierzy jest dość kosztowne obliczeniowo, ostatnio 
wyliczone tablice macierzy są zapamiętywane w liście struktur typu 
BoneMatrixCacheEntry. Procedura wyliczania macierzy kości dla podanej anima¬ 
cji i jej czasu (lub pary animacji i współczynnika interpolacji między nimi) wygląda 
w pseudokodzie następująco: 

BoneToParentPoseMat = MATRIX[] 

BoneToParentPoseMat[0] = IDENTITY 
if (Jedna animacja): 

foreach (Kość in Kości modelu): 
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float Scal = Animacja.Skalowanie(Kość, Czas) 

MATRIX ScalMat = Macierz skalowania (Scal) 

QUATERNION Rot = Animacja.Rotacja(Kość, Czas) 

MATRIX RotMat = Macierz rotacji (Rot) 

VEC3 Trans = Animacja.Translacja(Kość, Czas) 

MATRIX TransMat = Macierz translacji (Trans) 

BoneToParentPoseMat[Kość] = 

ScalMat * RotMat * TransMat * Kość.Macierz 
else: // Interpolacja między dwiema animacjami 
foreach (Kość in Kości modelu): 

float Scali = Animacjal.Skalowanie(Kość, Czasi) 
float Scal2 = Animacja2.Skalowanie(Kość, Czas2) 
float Scal = LERP od Scali do Scal2 wg LerpT 
MATRIX ScalMat = Macierz skalowania (Scal) 

QUATERNION Rotl = Animacjal.Rotacja(Kość, Czasi) 

QUATERNION Rot2 = Animacja2.Rotacja(Kość, Czas2) 

QUATERNION Rot = SLERP od Rotl do Rot2 wg LerpT 
MATRIX RotMat = Macierz rotacji (Rot) 

VEC3 Transl = Animacjal.Translacja(Kość, Czasi) 

VEC3 Trans2 = Animacja2.Translacja(Kość, Czas2) 

VEC3 Trans = LERP od Transl do Trans2 wg LerpT 
MATRIX TransMat = Macierz translacji (Trans) 

BoneToParentPoseMat[Kość] = 

ScalMat * RotMat * TransMat * Kość.Macierz 

BoneToModelPoseMat = MATRIX[] 

BoneToModelPoseMat[0] = IDENTITY 
foreach (Kość in Kości modelu): 

if (Kość jest pierwszego poziomu): 

BoneToModelPoseMat[Kość] = BoneToParentPoseMat[Kość] 
else: 

BoneToModelPoseMat[Kość} = BoneToParentPoseMat[Kość] * 
BoneToModelPoseMat[Kość.Kość_nadrzędna] 

BoneMatrices = MATRIX[] 

BoneMatrices[0] = IDENTITY 
foreach (Kość in Kości modelu): 

BoneMatrices[Kość] = ModelToBoneMatrices[Kość] * 

BoneToModelPoseMat[Kość] 
return BoneMatrices 

Każda z tablic zawiera w pierwszym elemencie macierz identycznościową, ponie¬ 
waż indeks O oznacza brak kości. Właściwe kości indeksowane są od 1. Dzięki temu 
wybrane wierzchołki siatki mogą pozostawać bez wpływu ze strony jakiejkolwiek kości 
(albo tylko pod częściowym wpływem). Wyliczane najpierw macierze 
BoneToParentPoseMat reprezentują przekształcenia ze współrzędnych danej kości do 
współrzędnych jej kości nadrzędnej w pozycji zgodnej z żądaną animacją. Z nich po¬ 
wstają następnie macierze BoneToModelPoseMat, które reprezentują przekształcenia 
ze współrzędnych danej kości do współrzędnych modelu, również w ustalonej pozycji. 
Wreszcie, ostateczne macierze BoneMatrices reprezentują, jak już zostało napisane 
wyżej, przekształcenie z pozycji spoczynkowej do pozycji ustalonej przez daną anima¬ 
cję w przestrzeni modelu. 

Trzeci etap jest wykonywany w czasie rzeczywistym i polega na zastosowaniu ma¬ 
cierzy kości do każdego wierzchołka siatki. Wierzchołki są zapisane w przestrzeni mo¬ 
delu, w pozycji spoczynkowej (ang. Bind Pose). Macierze kości przekształcają z tego 
układu do układu w przestrzeni modelu, ale w pozycji ustalonej przez daną animację. 
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Tak więc animowanie modelu polega na pomnożeniu danych wierzchołka przez ma¬ 
cierze kości, które na niego wpływają oraz zinterpolowaniu wyniku stosownie do wag 
wpływu tych kości. Kod Vertex Shadera, który to wykonuje, wygląda następująco: 

#if (SKINNING == 1) 

float3 SkinPos(float3 Pos, VS_INPUT Input) 

ł 

float3 OutputPos = 

mul(float4 (Pos, 1), BoneMatrices[Input.Bonelndices[0]]) * 

Input.BoneWeightO; 

OutputPos += 

mul(float4(Pos, 1), BoneMatrices[Input.Bonelndices[1]] ) * 

(1 - Input.BoneWeightO); 
return OutputPos; 

} 

half3 SkinNormal(half3 Normal, VS_INPUT Input) 

ł 

half3 OutputNormal = 

mul(Normal, (half3x3)BoneMatrices[Input.Bonelndices[0]]) * 

Input.BoneWeightO; 

OutputNormal += 

mul(Normal, (half3x3)BoneMatrices[Input.Bonelndices[1 ]] ) * 

(1 - Input.BoneWeightO) ; 
return OutputNormal; 

} 

#endif 

////// VERTEX SHADER 
float3 InputPos; 
half3 InputNormal; 
half3 InputTangent; 
half3 InputBinormal; 

#if (SKINNING == 1) 

InputPos = SkinPos(In.Pos, In); 

InputNormal = SkinNormal(In.Normal, In); 

InputTangent = SkinNormal(In.Tangent, In); 

InputBinormal = SkinNormal(In.Binormal, In); 

#else 

InputPos = In.Pos; 

InputNormal = In.Normal; 

InputTangent = In.Tangent; 

InputBinormal = In.Binormal; 

#endif 

Klasa QMesh potrafi wykonywać analogiczny algorytm na CPU dla potrzeb liczenia 
kolizji promienia z animowanym modelem. Odpowiedni kod znajduje się w metodzie 

RayCollision_Bones. 


3.5. Implementacja efektów cząsteczkowych 

Efekt cząsteczkowy, dostępny w silniku jako encja typu ParticleEntity, jest typu 
stanowego 1571 . Bufor wierzchołków jest wypełniany tylko raz, podczas inicjalizacji, a 
w czasie rzeczywistym parametry cząstek są wyliczane na GPU przez shader, którego 
kod można znaleźć w pliku ParticleShader. fx. Podczas tworzenia obiektu trzeba 
podać nazwę zasobu tekstury, tryb alfa-blendingu, liczbę cząstek oraz wypełnioną 
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strukturę PARTICLE_DEF. Struktura ta opisuje zmianę parametrów cząstek w czasie 
i składa się z następujących pól: 

struct PARTICLE_DEF { 
uint CircleDegree; 

VEC3 PosA2_C, PosA2_P, PosA2_R; 

VEC3 PosAl_C, PosAl_P, PosAl_R; 

VEC3 PosA0_C, PosA0_P, PosA0_R; 

VEC3 PosB2_C, PosB2_P, PosB2_R; 

VEC3 PosBl_C, PosBl_P, PosBl_R; 

VEC3 PosB0_C, PosB0_P, PosB0_R; 

VEC4 ColorA2_C, ColorA2_P, ColorA2_R; 

VEC4 ColorAl_C, ColorAl_P, ColorAl_R; 

VEC4 ColorA0_C, ColorA0_P, ColorA0_R; 

float OrientationAl_C, OrientationAl_P, OrientationAl_R; 

float OrientationAO_C, OrientationAO_P, OrientationAO_R; 

float SizeAl_C, SizeAl_P, SizeAl_R; 

float SizeA0_C, SizeA0_P, SizeA0_R; 

float TimePeriod_C, TimePeriod_P, TimePeriod_R; 

float TimePhase_C, TimePhase_P, TimePhase_R; 

} ; 


Pola oznaczone AO, Al, A2, BO, BI, B2 to parametry równania: 


v — A 2 • t 2 + A\ ■ t + Aq + B 2 ■ sin(i?i • t + Bq) 


(3.1) 


Pos to pozycja cząstki, w przestrzeni lokalnej obiektu. Color to kolor cząstki wraz 
z przezroczystością w kanale Alfa. Orientation to orientacja cząstki, czyli jej kąt ob¬ 
rotu w radianach wokół kierunku patrzenia kamery. Si ze to rozmiar cząstki, w prze¬ 
strzeni lokalnej modelu. Period to okres, czyli czas w sekundach, po którym cząstka 
powtarza swój bieg od początku. Phase to faza, czyli przesunięcie czasu [0; 1], dzięki 
któremu różne cząstki mogą być w danej chwili w różnym miejscu od swojej pozycji 
początkowej do końcowej. 

Pola z przyrostkiem C (od Const) oznaczają składnik stały parametru. Pola z przy¬ 
rostkiem P (od Particie Number) oznaczają składnik parametru mnożony przez liczbę 
[0; 1] zależną od numeru cząstki. Pola z przyrostkiem R (od Random) oznaczają skład¬ 
nik parametru mnożony przez zapamiętaną dla cząstki liczbę losową [0; 1]. 

Trzeba przyznać, że sterowanie tak zdefiniowanymi parametrami efektu cząstecz¬ 
kowego jest trudne, szczególnie dla nieprogramisty. Trudno też wyobrazić sobie spo¬ 
sób, w jaki mogłaby być umożliwiona ich wizualna edycja w specjalnym edytorze. 
Jednak przy odrobinie wprawy i z pomocą narzędzia wyliczającego współczynniki 
równania liniowego i kwadratowego na podstawie podanych punktów, otrzymywanie 
pożądanych rezultatów jest możliwe. W zamian, tak zaprojektowany system oferuje 
bardzo dużą elastyczność i szerokie możliwości sterowania zachowaniem cząstek przy 
jednoczesnej wysokiej wydajności. W sumie wzory obliczające parametry danej cząstki 
można zapisać w pseudokodzie następująco: 

TimePeriod = TimePeriod_C + TimePeriod_P * P + TimePeriod_R * R 
TimePhase = TimePhase_C + TimePhase_P * P + TimePhase_R * R 
t = frac(GlobalTime / TimePeriod + TimePhase) 
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ColorA2 = ColorA2_C + ColorA2_P * P + ColorA2_R * R 

ColorAl = ColorAl_C + ColorAl_P * P + ColorAl_R * R 

ColorAO = ColorA0_C + ColorA0_P * P + ColorA0_R * R 

OrientationAl = OrientationAl_C + OrientationAl_P * P + 

OrientationAl_R * R 

OrientationAO = OrientationAO_C + OrientationAO_P * P + 
OrientationAO_R * R 

SizeAl = S±zeAl_C + SizeAl_P * P + SizeAl_R * R 
SizeAO = SizeA0_C + SizeA0_P * P + SizeA0_R * R 

Pos = PosA2 * t A 2 + PosAl * t + PosAO + 

PosB2 * sin (PosBl * t + PosBO) 

Color = ColorA2 * t A 2 + ColorAl * t + ColorAO 
Orientation = OrientationAl * t + OrientationAO 
Size = SizeAl * t + SizeAO 

Struktura wierzchołka to: 

Struct PARTICLE_VERTEX 

{ 

VEC3 StartPos; // 

COLOR VertexFactors; // 

VEC2 ParticleFactors; // 

} 


Semantyka D3DFVF_XYZ 
Semantyka D3DFVF_DIFFUSE 
Semantyka D3DFVF_TEXCOORDSIZE2(0) 


Kreatywne wykorzystanie pól wierzchołka do celów innych niż oryginalnie przewi¬ 
dziane jest typowe dla zaawansowanych efektów realizowanych z użyciem shaderów. 
W powyższej strukturze pole StartPos wyznacza pozycję początkową cząstki. Pole 
VertexFactors przechowuje w swoich składowych RGB kolejno: R — kąt charakte¬ 
rystyczny dla wierzchołka cząstki, mapowany przez Vertex Shader z przedziału [0; 1] 
do [l7r/4; 77 t/ 4], G — współrzędna tekstury t x , równa O lub 1, B — współrzędna tek¬ 
stury t y , równa O lub 1. Wykorzystanie semantyki koloru Diffuse pozwoliło zmieścić 
te trzy wartości do pojedynczej liczby 32-bitowej, co oszczędza pamięci zapewniając 
precyzję wystarczającą do tych zastosowań. Warto dodać, że pola tego typu są w ko¬ 
dzie C++ bajtami o wartościach [0; 255], ale w kodzie shadera HLSL stają się liczbami 
zmiennoprzecinkowymi [0.0; 1.0]. Pole ParticleFactors w komponencie x przecho¬ 
wuje współczynnik charakterystyczny cząstki [0; 1] zależny liniowo od numeru cząstki 
(P), a w komponencie y przechowuje współczynnik losowy cząstki [0; 1] (R). 

Współczynnik losowy cząstki R nie może być pojedynczy, ponieważ wówczas, jeśli 
na przykład od niego zależałaby zarówno pozycja y jak i kolor, cząstki znajdujące się 
wyżej były równocześnie jaśniejsze, co zepsułoby wizualnie efekt losowości. Dlatego 
Vertex Shader efektu cząsteczkowego generuje na podstawie współczynnika losowego, 
pobranego ze struktury wierzchołka, trzy współczynniki, które wykorzystuje potem w 
różnej kolejności. Odpowiedni kod HLSL to: 

float ParticleP = In.ParticleFactor.x; 

float3 ParticleR = frac(In.ParticleFactor.yyy * 
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float3 (324.2135, 231.3542, 147.4534)); 

11/1 // Jedna z instrukcji wykorzystujących te współczynniki: 
float4 ColorAl = Data[3] + Data [4] * ParticleP + 

Data[5] * ParticleR.yzxy; 

Cząsteczki są rysowane jako kwadraty zbudowane z dwóch trójkątów, zwrócone 
zawsze przodem do kamery. Istnieje wprawdzie mechanizm sprzętowego zamieniania 
pojedynczych wierzchołków na takie kwadraty — Point Spńtes — jest nie został on 
tutaj użyty, gdyż do tak zaawansowanego systemu cząsteczkowego jest niewystarcza¬ 
jący. Nie ma on możliwości obracania cząstek, a na kartach bez D3DFVFCAPS_PSIZE 
(m.in. GeForce FX) także zmiany wielkości poszczególnych cząstek. 

Dlatego opisany tutaj efekt cząsteczkowy jawnie podaje po 4 wierzchołki i 6 indek¬ 
sów na każdą cząstkę, by z nich zbudować taki kwadrat. Parametry cząstki muszą 
być od nowa wyliczone dla każdego z jej wierzchołków osobno (tak działa Vertex Sha- 
der). Dlatego wszystkie wierzchołki danej cząstki mają zapisane te same parametry, 
z wyjątkiem opisanego wyżej pola VertexFactors, które pozwala je rozróżnić „roz¬ 
suwając” wierzchołki od pozycji środka cząstki w kierunku zgodnym z wektorami „w 
prawo” i „w górę” pobranymi z kamery oraz nakładając odpowiednie teksturowanie, 
tak jak to pokazuje rysunek |3.6[ Tych czynności dokonują kończące instrukcje Vertex 
Shadera: 



Rys. 3.6. Kwadrat przedstawiający cząsteczkę, zbudowany z 4 wierzchołków odsuwanych od 
pozycji środka cząsteczki zgodnie z wektorami kamery „w prawo” i „w górę”. 


float HalfSizeDiagonal = Size * (1.41421356237309504880 / 2); 

// Mapowanie 0 .. 1 na 1/4*PI .. 7/4*PI 
// Wzór który to robi: y = 3/2*PI * x + 1/4*PI 
float Angle = In.VertexFactors.r * 4.71238898 + 0.785398163 + 
Orientation; 

Pos = Pos + (RightDir * cos(Angle) + UpDir * sin(Angle)) * 

HalfSizeDiagonal; 

Out.Pos = mul(float4(Pos, 1), WorldViewProj); 

Out.Color = Color; 

Out.Tex = float2(In.VertexFactors.g, In.VertexFactors.b); 

Pozycja początkowa cząstek jest wyliczana na CPU tylko raz, podczas tworzenia 
encji efektu cząsteczkowego i zostaje zapisana do wierzchołków. Dlatego może być wy¬ 
liczana wg bardziej skomplikowanych zależności. Zostało to wykorzystane do umożli¬ 
wienia generowania pozycji początkowej cząstek z obszaru o różnym kształcie. Steruje 
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tym pole CircleDegree struktury PARTICLE_DEF. Jeśli wynosi ono 0, współczynniki 
AO posiadają dosłowną interpretację, wyznaczając zakres [(ag, yi, z\)\ (x 2 ,y 2 ,* 2 )]. z któ¬ 
rego mają być generowane pozycje cząstek. Pozwala to otrzymać obszar generowania 
w kształcie punktu, odcinka, prostokąta lub prostopadłościanu. Jeśli CircleDegree 
jest równe 1, pozycje początkowe są generowane z okręgu, koła lub walca o podstawie 
równoległej do osi XZ. Składowe y parametru AO wyznaczają zakres y\ ... ip , skła¬ 
dowe x opisują promień, a składowe z kąt. Jeśli natomiast CircleDegree jest równe 
2, emiter cząstek ma kształt kuli, składowe x opisują promień, składowe y pierwszy 
kąt (długość geograficzną), a składowe z drugi kąt (szerokość geograficzną). Przykłady 


pokazuje rys. 3.7 
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Rys. 3.7. Przykładowe kształty obszarów, z których wybrane mogą być pozycje początkowe 
cząsteczek, zależnie od parametrów struktury PARTICLE_DEF. 


Przykładowe efekty działania systemu cząsteczkowego prezentuje zrzut ekranu [4. 8 [ 
W efekcie pierwszym od lewej kolory cząstek zależą od współczynnika losowego R, ale 
ich pozycja jest opisana wyłącznie z użyciem współczynnika P, zależnego od numeru 
cząstki. Dzięki temu poszczególne cząstki są od siebie umieszczone w równych od¬ 
stępach. Wszystkie mają tą samą pozycję początkową i poruszają się po tej samej 
krzywej w kształcie spirali. Każda jest w innym miejscu krzywej dzięki uzależnieniu 
fazy od numeru cząstki: TimePhase_C=0, TimePhase_P=l. Z kolei efekt ognia wi¬ 
doczny po prawej stronie tworzą cząstki, których parametry (szczególnie pozycja i tor 
ruchu) zależą od współczynnika losowego R, co daje wrażenie przypadkowości. 


3.6. Implementacja efektów postprocessingu 

Proste efekty postprocessingu, takie jak zamalowanie całego ekranu na podany ko¬ 
lor (klasa PpColor) czy podaną teksturą (klasa PpTexture) nie wymagają dokładnego 
omówienia. Ich realizacja polega na narysowaniu prostokąta pokrywającego cały ob¬ 
szar ekranu (ang. Fullscreen Quad) z włączonym alfa-blendingiem. Warto dodać, że 
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takie proste technicznie efekty mogą być bardzo ważne. Na przykład na początku 
i przy zakończeniu gry ekran może się płynnie rozjaśniać/ściemniać do czarnego, 
a podczas otrzymywania obrażeń przez bohatera może się robić czerwony. Innym przy¬ 
kładem takiego prostego efektu jest losowe przesuwanie („trzęsienie”) kamery podczas 
eksplozji. 


Realizacja efektu funkcji Efekt zaimplementowany w klasie PpFunction pozwala 
na przekształcenie wszystkich pikseli rysowanego obrazu za pomocą pewnej funkcji, 
której współczynniki można zmieniać. Funkcję tą można przedstawić w pseudokodzie 
jako: 

color Kolor_grayscale.rgb = Odcień szarości (Kolor_we) 

Kolor_wy = LERP od Kolor_we do Kolor_grayscale wg GrayscaleFactor 
Kolor_wy = Kolor_wy * A_factor + B_factor 
return Kolor_wy 

Trzy współczynniki sterujące tą funkcję zapewniają bardzo szeroką gamę możliwo¬ 
ści, na przykład: 

• GrayscaleFactor= 0, A_factor= (v,v,v), B_factor=(0,0,0) pozwala regulować 
jasność, 

• GrayscaleFactor= 0, A_f actor= ( v , v, v), B_f actor= (0.5 — 0.5r, 0.5 — 0.5u, 0.5 — 
0.5r) pozwala regulować kontrast, 

• GrayscaleFactor= 1 — v, A_factor= (1,1,1), B_factor= (0,0,0) pozwala regu¬ 
lować nasycenie, 

• GrayscaleFactor= 1, A_factor= (1,1,1), B_factor= (0,0,0) zamienia obraz na 
odcienie szarości, 

• GrayscaleFactor= 1, A_factor(l, 1,1), B_factor= (0.191,-0.054,-0.221) daje 
efekt sepii, 

• GrayscaleFactor= 1, A_factor= (—1,— 1, — 1), B_factor= (1,1,1) odwraca ko¬ 
lory, 

• GrayscaleFactor= 0, A_factor= (1,0,0), B_factor= (0,0,0) pokazuje tylko ka¬ 
nał czerwony. 


Implementacja tego efektu opiera się na przepisaniu obrazu z tekstury, do której 
renderowana jest scena, do bufora ramki, za pomocą multishadera PpShader (patrz 
rys. 3.8} . On wykonuje także inne czynności związane z różnymi efektami postpro- 
cessingu, dlatego jest kompilowany na żądanie z takim zestawem możliwości, jakie są 
w danej chwili potrzebne. 


Realizacja efektu Tonę Mapping Efekt udający Tonę Mapping z HDR polega na 
przyciemnianiu lub rozjaśnianiu obrazu, zależnie od jego średniej jasności. Algorytm 
wygląda następująco: 

1. Scena zostaje wyrenderowana do tekstury pomocniczej. 
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Rys. 3.8. Podczas używania niektórych efektów postprocessingu następuje narysowanie 
sceny do pomocniczej tekstury, z której dopiero zostaje przerysowana do bufora ramki za 

pomocą shadera PpShader. 


2. Metoda CalcBrightness klasy PpToneMapping kopiuje najpierw tą teksturę 
do dodatkowej tekstury pomocniczej udostępnianej przez Eng±neServices jako 
ST_TONE_MAPPING_VRAM, która ma wielkość równą 1/50 rozdzielczości ekranu. 

3. Zawartość tej tekstury zostaje sprowadzona z karty graficznej do pamięci RAM 
za pomocą funkcji Direct3D GetRenderTargetData. 

4. Metoda MeasureBrightness próbkuje wybrane miejsca tej tekstury i na tej pod¬ 
stawie szacuje średnią jasność obrazu. 

5. Podczas przerysowania obrazu do bufora ramki, PpShader reguluje jasność ob¬ 
razu na podstawie danych pobranych z klasy PpToneMapping. 

Ponieważ sprowadzanie zawartości tekstury z pamięci karty graficznej do pamięci 
systemowej jest bardzo niewydajne, klasa robi to tylko co określony czas, a nie w każ¬ 
dej klatce. Ponadto zmiana rejestrowanej jasności jest wygładzana i reaguje z pewnym 
opóźnieniem, co daje naturalny efekt imitujący adaptację źrenicy oka. 

Realizacja efektu Bloom Efekt Bloom jest częścią imitacji HDR i pozwala przedsta¬ 
wić obszary, które wyglądają jakby były „jaśniejsze niż białe”. Przykład pokazuje rys. 



Rys. 3.9. Przykład sporządzony w programie graficznym obrazuje efekt Bloom (dwa ostatnie 

paski). 

1. Scena zostaje wyrenderowana do tekstury pomocniczej. 

2. Metoda CreateBloom z klasy PpBloom przerysowuje obraz między dwiema tek¬ 
sturami pomocniczymi, wykonując najpierw przebieg pozostawiający tylko miej¬ 
sca jasne (BrightPass ), a następnie dwuetapowe rozmycie filtrem Kawase’a opi¬ 
sanym w |55l ( BlurPass ). Wynik zostaje zachowany w dodatkowej teksturze po¬ 
mocniczej ST_BLUR_1. Tekstury pomocnicze ST_BLUR_1 i ST_BLUR_2 są 4 razy 
mniejsze od rozdzielczości ekranu, co nie tylko oszczędza pamięć i przyspiesza 
przetwarzanie, ale dzięki filtrowaniu liniowemu powoduje dodatkowe rozmycie. 
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3. Zawartość tekstury głównej z obrazem zostaje przerysowana do bufora ramki. 
Ten efekt nie ma wpływu na to przerysowanie. 

4. Na obraz w buforze ramki dorysowana zostaje tekstura ST_BLUR_1 z blendingiem 
addytywnym. 


Cały proces ilustruje rys 3.10 



Rys. 3.10. Proces powstawania efektu Blooom jako dodatkowe, addytywne nakładanie na 

obraz jego przetworzonej wersji. 


Realizacja efektu sprzężenia zwrotnego Efekt sprzężenia zwrotnego został wyko¬ 
nany na podstawie (3J. Polega na narysowaniu na obrazie nowej klatki półprzezroczy¬ 
stej, nieco przekształconej (np. przesuniętej, przeskalowanej, obróconej) wersji klatki 
poprzedniej. To pozwala uzyskać szereg efektów takich jak prosta imitacja rozmycia 
ruchu (ang. Motion Biur ) dla całego ekranu. Algorytm wykonania tego efektu jest 
następujący: 

1. Obraz nowej klatki jest rysowany do bufora ramki. Nieistotne jest przy tym, czy 
wcześniej był rysowany poprzez pomocniczą teksturę i PpShader). 

2. Metoda PpFeedback: Oraw najpierw nakłada na obraz w buforze ramki obraz 
z klatki poprzedniej, zapamiętanej w dodatkowej teksturze pomocniczej 
ST_FEEDBACK, w postaci półprzezroczystej i odpowiednio przekształconej. 

3. Następnie ta sama metoda przerysowuje końcowy obraz ekranu do tekstury 
ST_FEEDBACK celem wykorzystania w następnej klatce. 

Tekstura pomocnicza ST_FEEDBACK ma rozmiar 2 razy mniejsze od rozdzielczości 
bufora ramki. To przyspiesza renderowanie i oszczędza pamięci, a zarazem nie daje 
widocznego zmniejszenia jakości obrazu, ponieważ obraz rysowany z tej tekstury i tak 
jest półprzezroczysty. 


Realizacja efektu błysku soczewek Efekt błysku soczewek został wykonany na 
podstawie |3). Polega na narysowaniu na obrazie końcowym, w sposób dwuwymia¬ 
rowy, przygotowanych specjalnie w tym celu różnych tekstur błysków, ułożonych w li¬ 
nii prostej łączącej pozycję Słońca na ekranie z środkiem ekranu, tak jak to ilustruje 
rys. 


3.11 


Algorytm wykonania całości efektu wygląda następująco: 


124 






3. Implementacja silnika 



Rys. 3.11. Efekt błysku soczewek jako dwuwymiarowe kwadraty rysowane wzdłuż linii 
łączącej pozycję Słońca ze środkiem ekranu. 

1. Klasa Scene po narysowaniu wszystkich obiektów sceny (obojętne czy do tek¬ 
stury pomocniczej, czy wprost do bufora ramki) sprawdza i zwraca w metodzie 
QuerySunVisibleFactor widoczność Słońca za pomocą zapytania sprzętowego 
o zasłanianie (ang. Occlusion Query). 

2. Pod koniec całego procesu rysowania, kiedy już w buforze ramki znajduje się cały 
obraz 3D, metoda Draw klasy PpLensFlare dorysowuje półprzezroczyste błyski 
soczewek. 

Realizacja efektu mgły ciepła Efekt mgły ciepła (ang. Heat Haze) został wykonany 
na podstawie 1561 . Polega on na „falowaniu” obrazu w wyznaczonych miejscach, które 
mają imitować rozgrzane powietrze, np. nad ogniskiem czy płomieniem świecy. Jego 
algorytm wygląda następująco: 

1. Na początku renderowania sceny, metoda CreateDrawData wyznacza zbiór „en- 
cji ciepła” typu HeatEntity widocznych w zasięgu kamery. 

2. Scena jest renderowana do tekstury pomocniczej (nie bezpośrednio do bufora 
ramki). 

3. Kanał Alfa tekstury pomocniczej zostaje wyzerowany. Direct3D nie posiada moż¬ 
liwości czyszczenia tylko wybranych kanałów w metodzie elear, tak więc zostało 
to zrealizowane poprzez narysowanie pełnoekranowego prostokąta z zablokowa¬ 
niem kanałów RGB za pomocą ustawienia D3DRS_C0L0RWRITEENABLE. 

4. Metoda DrawHeatEntities sceny renderuje encje ciepła do kanału alfa tekstury 
pomocniczej. W kanale tym znajduje się więc intensywność „falowania powietrza” 
w danym miejscu. 

5. Podczas przerysowania tekstury pomocniczej do bufora ramki, PpShader prze¬ 
suwa współrzędne próbkowania tej tekstury względem oryginalnych tak, aby ob- 
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raz był zniekształcony. Stopień tego przesunięcia dobiera na podstawie kanału 
alfa tekstury pomocniczej, a kierunkiem przesunięcia sterują wektory zapisane 


w kanałach RG specjalnej tekstury Perturbation Map, pokazanej na rys. 3.12 



Rys. 3.12. Tekstura narzędziowa Perturbation Map, w której jako kanały RG zapisane są 
wektory sterujące kierunkiem przesunięcia współrzędnych tekstury do próbkowania obrazu. 


3.7. Renderowanie terenu 


W przypadku scen typu otwartego, teren, czyli pofałdowana powierzchnia modelująca 
trawę, piasek itd., stanowi podłoże dla całego wirtualnego świata i wymaga specjal¬ 
nego potraktowania. Zbudowany jest z regularnej siatki, której wierzchołki ułożone są 
w równych odstępach w płaszczyźnie XZ, a ich wysokość y jest zależna od tzw. mapy 
wysokości (ang. Heightmap). Mapa wysokości to specjalna tekstura w odcieniach 


szarości, w której jasność pikseli wyznacza wysokość (patrz rys. 3.13 



Rys. 3.13. Przykładowa mapa wysokości terenu. 


Ponieważ generowanie siatki terenu na podstawie mapy wysokości jest procesem 
stosunkowo kosztownym obliczeniowo, wyniki są zapamiętywane do ponownego uży¬ 
cia w pliku binarnym, dzięki czemu siatka generowana jest tylko za pierwszym razem. 

Kamera obejmuje swoim zasięgiem duży obszar terenu, z czego większość to frag¬ 
menty odległe. Dlatego zachodzi potrzeba nie tylko wybierania tych fragmentów te¬ 
renu, które są widoczne w obszarze kamery, ale również dostosowania ich poziomu 
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szczegółowości do odległości od kamery. W tym celu zastosowany został Geomip- 
mapping l39l . Ta prosta i skuteczna technika polega na podziale siatki terenu na 
kwadratowe sektory. Każdy sektor posiada kilka poziomów szczegółowości. W prak¬ 
tyce wystarczają odpowiednio skonstruowane bufory indeksów adresujące ten sam 
bufor wierzchołków. Ponadto jeden bufor indeksów może służyć do renderowania 
dowolnych sektorów terenu. Poziom szczegółowości danego sektora jest wybierany 
automatycznie na podstawie odległości tego sektora od kamery. Przykład pokazuje 
rys. 


3.14 



Rys. 3.14. Poziom szczegółowości sektorów terenu zostaje automatycznie dobrany zależnie 

od odległości sektora od kamery. 


Na łączniach między sektorami o różnych poziomach szczegółowości mogą powstać 
„pęknięcia” (ang. Cracks). Aby im zapobiec, wykorzystana została prosta technika 
opisana w |40| . Polega ona na dodaniu do geometrii sektora dodatkowej „spódniczki” 
(ang. Skirt), która zapełnia ewentualne pęknięcia teksturą minimalizując niepożądany 


efekt. Pełną siatkę pojedynczego sektora terenu pokazuje rys. 3.15 


Sektory terenu nie są zapamiętane w żadnej strukturze drzewiastej takiej jak drzewo 
czwórkowe, ale stanowią po prostu dwuwymiarową tablicę. Sektory widoczne w za¬ 
sięgu kamery są wybierane na podstawie testu przecięcia frustuma z AABB otacza¬ 
jącym dany sektor. Dzięki niemu odrzucenie sektora może się odbywać nie tylko 
w płaszczyźnie XZ, ale i w osi Y, jeśli na przykład kamera jest zwrócona do góry. 

Oprócz pozycji wierzchołków, siatka terenu potrzebuje także wektorów normal¬ 
nych używanych w oświetleniu i danych do teksturowania. Wektory normalne można 
policzyć zoptymalizowanym wzorem przedstawionym w l40l . który uwzględnia pozycje 
4 wierzchołków otaczających dany wierzchołek. Autor opracował jednak własny algo¬ 
rytm, który wymaga znacznie więcej obliczeń, ale w zamian daje dużo lepsze rezultaty, 
ponieważ uwzględnia wszystkie 8 wierzchołków dookoła danego. Kod tej procedury 
zawarty jest w metodzie Terrain_pimpl: : CalcNormals. 

Teren nie może być zazwyczaj pokryty pojedynczą teksturą. Zachodzi potrzeba 
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Rys. 3.15. Pojedynczy sektor terenu wraz z dodatkową geometrią zapobiegającą szczelinom 

na łączeniach między sektorami. 


wybierania różnych „form terenu” — trawy, piasku, śniegu, ziemi itp. oraz płynnego 
przechodzenia między nimi. Popularną metodą stosowaną w tym celu jest Texture 
Splatting opisany w 1431 . Autor opracował jednak własne rozwiązanie, w którym za¬ 
miast na osobnej teksturze, dane na temat formy terenu są zapisane w strukturze 
wierzchołka. 

Na opis form terenu składają się dwa pliki. Pierwszy to plik tekstowy w specjalnym 
formacie, którego przykład pokazuje poniższy listing: 

TerrainForms 1 
0x000000 complex { 

0 { 

"Sand" 

TexScale = 0.234 

} 

50 { 

"Grass" 

TexScale = 0.345 

} 

162 { 

"Snów" 

TexScale = 0.294 

} 

} 

0xFF0000 simple { 

"Path" 

TexScale = 0.678 

} 

0x00FF00 simple { 

"Creep" 

TexScale = 0.938 


Drugi plik to mapa form terenu zapisana w specjalnej teksturze, której przykład 


pokazuje rys. 3.16 Analizując obydwa te pliki można zauważyć, że kolor czerwony 
(0xFF0000) wyznacza „ścieżkę” (miejsca rysowane teksturą "Path" ze skalowaniem 
0.678), a kolor zielony (0x00FF00) wyznacza miejsca rysowane teksturą "Creep". Ko- 
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lor czarny (0x000000), pokrywający większość tekstury, jest zdefiniowany w pliku 
tekstowym jako forma złożona, w której wybór konkretnej tekstury jest zależny od 
wysokości. Obszary powyżej wysokości 162 (wysokość terenu jest w zakresie 0 ... 255) 
to śnieg, obszary powyżej 50 to trawa, a niższe to piasek. 




Rys. 3.16. Przykładowa mapa form terenu. Kolory wyznaczają poszczególne formy terenu. 

Na podstawie tych dwóch plików obliczone zostają formy terenu używane przez 
każdy z sektorów. Na jednym sektorze używane mogą być co najwyżej 4 formy te¬ 
renu. Do wierzchołków siatki terenu, których struktura jest pokazana poniżej, wpi¬ 
sane zostają (jako kanały ARGB elementu Dif fuse) wagi blendingu poszczególnych 
form terenu w danym miejscu. 


struct VERTEX 

{ 

VEC3 Pos; // Semantyka D3DFVF_XYZ 

VEC3 Normal; // Semantyka D3DFVF_NORMAL 
COLOR Diffuse; // Semantyka D3DFVF_DIFFUSE 


Następnie podczas rysowania danego sektora terenu, MainShader z włączonym 
makrem TERRAIN wykonuje samplowanie wszystkich 4 tekstur, a następnie ich mie¬ 
szanie zależnie od ich wag w danym wierzchołku: 


////// VERTEX SHADER 

Out.TerrainTextureWeights = 

(...) 

half2 Tex = half2(In.Pos.x. 
Out.TerrainTexO1.xy = Tex * 
Out.TerrainTexO1.zw = Tex * 
Out.TerrainTex23.xy = Tex * 
Out.TerrainTex23.zw = Tex * 


In.TerrainTextureWeights; 

In.Pos.z); 

TerrainTexScale.x; 

TerrainTexScale.y; 

TerrainTexScale.z; 

TerrainTexScale.w; 


1 / 111 / PIXEL SHADER 

MyDiffuseColor = tex2D(TerrainSamplerO, In.TerrainTex01.xy); 
MyDiffuseColor = lerp(MyDiffuseColor, tex2D(TerrainSamplerl, 
In.TerrainTex01.zw) , In.TerrainTextureWeights.a); 

MyDiffuseColor = lerp(MyDiffuseColor, tex2D(TerrainSampler2, 
In.TerrainTex23.xy), In.TerrainTextureWeights.r); 

MyDiffuseColor = lerp(MyDiffuseColor, tex2D(TerrainSampler3, 
In.TerrainTex23.zw), In.TerrainTextureWeights.g); 

Out = MyDiffuseColor; 
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3.8. Efekt opadów atmosferycznych 


Opady atmosferyczne takie jak deszcz i śnieg to zjawisko trudne do realistycznego za- 
modelowania. Autor wymyślił w tym celu własny sposób renderowania, który składa 


się z trzech elementów. Budowę efektu pokazuje rys. 3.17 



Na scenie typu otwartego kamera pokazuje rozległy obszar i rysowanie każdej 
cząstki spadającego deszczu czy śniegu nie jest dobrym pomysłem, bo musiałoby 
ich być bardzo dużo. Z drugiej strony, rysowanie płaszczyzny pokrytej przewijaną 
teksturą przedstawiającą „ścianę deszczu” tuż przed kamerą mogłoby być zbyt za¬ 
uważalne i wyglądać nienajlepiej. 

Dlatego autor połączył obydwa te podejścia. Prostokąty, oznaczone na wspomnia¬ 
nym rysunku kolorem czerwonym, są pokryte teksturą prezentującą pojedyncze kro¬ 


ple deszczu albo płatki śniegu, pokazane na rys. 3.18 a). W ten sposób rysowane 
są opady w pobliżu kamery. Dalej znajduje się kilka obręczy (pokazanych na rys. 
3.17|w kolorze zielonym), pokrytych teksturą prezentującą całą grupę cząstek (poka¬ 


zaną na rys. 3.18 b). Symulują one opady w dalszej odległości od kamery. Trzecim 
składnikiem efektu są dodatkowe, duże prostokąty rysowane w pobliżu kamery (kolor 
niebieski na rys. 3.17} i pokryte teksturą szumu (rys. 3.18 c), które są symulacją 
„zamieci” — bardzo intensywnych opadów. 

Tworzenie efektu opadów atmosferycznych, reprezentowanego przez klasę Fali, 
odbywa się z podaniem wypełnionej struktury FALL_EFFECT_DESC. Jej pola opisują 
dany efekt i nie podlegają zmianie w czasie jego działania. Częścią pierwszą efektu 
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a) 




Rys. 3.18. Tekstury używane podczas rysowania opadów atmosferycznych: a) pojedyncza 
cząsteczka śniegu, b) grupa cząsteczek śniegu, c) szum do „zamieci”. 


(pojedyncze cząsteczki) sterują pola: ParticleTextureName określające teksturę czą¬ 
steczki, ParticleHalf Size określające szerokość i wysokość cząsteczki, UseRealUpDir 
określające sposób zwracania prostokątów cząsteczek przodem do kamery, 
MovementVecl i MovementVec2 wyznaczające zakres kierunków ruchu cząsteczek. 
Częścią drugą efektu (obręcze z przewijaną teksturą opadów) sterują pola: 
PlaneTextureName określające teksturę grupy cząsteczek, PlaneTexScale określa¬ 
jące skalowanie współrzędnych tej tekstury. Ponadto określić trzeba kolor, przez który 
mnożone mają być próbki z tekstur. Tekstury są bowiem białe (na rysunkach tutaj 
przedstawione są w negatywie). 

Podczas trwania efektu sterować można jego ogólną intensywnością podając liczbę 
0... 1. Klasa automatycznie przekłada ją na parametry poszczególnych składników 
efektu (liczba bliskich cząstek, liczba dalszych obręczy, liczba prostokątów „zamieci” 
itp.). Ponadto klasa uwzględnia pobrany ze sceny wektor wiatru, aby przedstawić 
opady stosownie do jego kierunku i intensywności. Zostało to zrealizowane za pomocą 
zaaplikowania do całej rysowanej przez tą klasę geometrii dodatkowego przekształce¬ 
nia ścinania (ang. Shearing). 

Dzięki możliwości określenia wielu parametrów i podania dowolnych tekstur, efekt 
opadów atmosferycznych jest bardzo elastyczny i daje duże możliwości. W demie 
dołączonym do pracy został wykorzystany do otrzymania deszczu i śniegu, ale równie 
dobrze może posłużyć do przedstawienia burzy piaskowej na pustyni, pyłków lecących 
od podłoża do góry, jakiś magicznych cząstek latających w różne strony itd. 


3.9. Renderowanie trawy 

Renderowanie trawy jest wyzwaniem, gdyż wymaga bardzo dużej ilości geometrii. 
Mimo że poszczególne źdźbła trawy nie są modelowane za pomocą trójkątów, ale ich 
obraz powstaje poprzez rysowanie równoległoboków przedstawiających teksturę całej 
kępki trawy, potrzebne jest wiele wierzchołków. Dlatego trawa rysowana jest tylko 
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w pobliżu kamery i płynnie zanika wraz z odległością. 

Ponieważ trawa nie używa alfa-blendingu, tylko testu Alfa, zanikanie zostało zre¬ 
alizowane za pomocą techniki opisanej w 1471 . Wartość Alfa odczytana z tekstury 
trawy jest modyfikowana przez jasność pobraną z tekstury przedstawiającej rozmyty 
szum, pokazanej na rys. 3. 19[ odpowiednio przesuniętą zależnie od odległości do 
kamery. W ten sposób, im dalej dany trójkąt znajduje się od kamery, tym większy 
procent losowych pikseli jest niewidoczny. Intuicyjnie mogłoby się wydawać, że taka 
technika będzie wyglądała brzydko, że ąuady z trawą będą „powygryzane”. W praktyce 
jednak sprawdza się bardzo dobrze, bo ąuadów jest wiele i uwaga odbiorcy skupia się 
na ogólnym wrażeniu, nie na poszczególnych fragmentach trawy. 



Rys. 3.19. Tekstura narzędziowa przedstawiająca rozmyty szum, używana do realizacji 

zanikania trawy z odległością. 


Struktura wierzchołka trawy wygląda następująco: 

struct VERTEX { 

VEC3 Pos; 

COLOR Diffuse; 

VEC2 Tex; 

} ; 

Składowe ARGB elementu Diffuse zostały wykorzystane do zapisania dodatko¬ 
wych danych: R i G oznaczają rozsunięcie wierzchołka od środka ąuada odpowiednio 
w osi poziomej (w kierunku wektora „w prawo” kamery) i w osi pionowej (w kierunku 
wektora „do góry” kamery). Są przekształcane do zakresu —2...2. B i A oznaczają 
losowe współczynniki wpływu odpowiednio pierwszego i drugiego wektora wiatru na 
dany wierzchołek. Są przekształcane do zakresu —1... 1. Współrzędne tekstury Tex 
są losowo odwracane w osi pionowej, aby jedne fragmenty trawy były lustrzanym od¬ 
biciem innych. To wprowadza dodatkową różnorodność. 

Quady przedstawiające fragmenty trawy są rysowane w podobny sposób, jak czą¬ 
steczki w efekcie cząsteczkowym. Każdemu ąuadowi odpowiadają 4 wierzchołki i 6 in¬ 
deksów, tworząc 2 trójkąty. Wszystkie 4 wierzchołki mają zapisaną tą samą pozycję — 
pozycję środka ąuada — i są od niej rozsuwane w kierunku wektorów „w prawo” i „do 
góry” pobranych z kamery. Dodatkowo niektóre wierzchołki (górna krawędź ąuada) są 
przesuwane w kierunku „w prawo” przez współczynnik służący do otrzymania efektu 
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falowania trawy na wietrze. Aby nie wszystkie fragmenty trawy poruszały się w tym 
samym kierunku, do shadera są przekazywane dwa współczynniki wiatru i w każdym 
wierzchołku ich wpływ jest ważony przez komponenty B i A elementu Diffuse. Oto 
kod shadera używanego do renderowania trawy: 

void GrassVS(VS_INPUT In, out VS_OUTPUT Out) 

{ 

floatż QuadBias = In.Diffuse.rg * 4 - 2; 
floatż Randoms = In.Diffuse.ba *2-1; 
float Wind = dot(WindFactors, Randoms); 

float3 WorldPos = In.Pos + (QuadBias.x + Wind) * RightDir + 
QuadBias.y * UpDir; 

Out.Pos = mul(float4(WorldPos, 1), ViewProj); 

Out.Tex = In.Tex; 

Out.NoiseTex.xy = float2(WorldPos.x + WorldPos.z, WorldPos.y); 

Out.NoiseTex.z = Out.Pos.z; 

} 

void GrassPS(VS_OUTPUT In, out half4 Out : COLORO) 

{ 

Out = tex2D(Sampler, In.Tex) * Color; 
float Pos_z = In.NoiseTex.z; 

float MyFadeFactor = Pos_z * FadeFactors.x + FadeFactors.y; 
float Fade = tex2D(NoiseSampler, In.NoiseTex) + MyFadeFactor; 

Out.a *= saturate(Fade); 

} 

Gatunki trawy opisuje plik tekstowy w specjalnym formacie, podawany przy two¬ 
rzeniu obiektu klasy Grass jako GrassDescFileName. Oto przykładowa treść: 

GrassDesc 
Texture { 

"GrassTexture" 

512, 128 

} 

Grasses { 

"Grass" { 

CX = 0.7, 0.1 
CY = 0.5, 0.05 
Tex = 0, 0, 207, 127 
Wind = 1 

} 

"Flower" { 

CX = 0.5, 0.1 

CY = 0.5, 0.05 

Tex = 257, 0, 397, 127 

Wind = 0.8 

} 

"Stone" { 

CX = 0.1, 0.05 

CY = 0.05, 0.03 

Tex = 415, 39, 483, 72 

Wind = 0 

} 

} 

DensityMap { 

R { 

"Stone" 5 

} 

G { 

"Grass" 5, 

} 
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"Grass" 5, 
"Flower" 2 

} 

} 


Wszystkie rodzaje obiektów muszą występować na wspólnej teksturze. Powyższy 
przykład definiuje 3 takie rodzaje: trawa, kwiat i kamień. Są one wyznaczone przez 
parametry: CX, CY — szerokość i wysokość ąuada, we współrzędnych świata, Tex — 
prostokąt wyznaczający obraz danego rodzaju obiektu na teksturze w pikselach, Wind 
— stopień wpływu wiatru (kamień w ogóle nie kołysze się na wietrze). 

Ostatnia sekcja pliku tekstowego definiuje znaczenie kanałów RGB na specjalnej 
teksturze podawanej podczas tworzenia efektu jako DensityMapFileName. Tekstura 
ta wyznacza miejsca na terenie, które mają być pokryte poszczególnymi rodzajami 


trawy oraz jej intensywność. Przykład takiej tekstury pokazuje rys. 3.20 Na przykład 
na fragmencie terenu, któremu na tej teksturze odpowiada piksel o intensywności 
składowej niebieskiej 255, powstanie 5 ąuadów trawy i 2 ąuady kwiatów, natomiast 
tam, gdzie piksel ma kolor czerwony o intensywności 100, powstaną 2 kamienie. Po¬ 
szczególne ąuady są rozlokowane w losowych miejscach w ramach danego fragmentu 
terenu wyznaczanego przez sąsiednie wierzchołki mapy wysokości. 



Ponieważ generowanie geometrii trawy jest kosztowne obliczeniowo, wygenerowana 
geometria dla ostatnio wyświetlanych sektorów terenu jest spamiętywana do ponow¬ 
nego użycia. 


3.10. Renderowanie nieba 

Niebo reprezentowane przez klasę ComplexSky jest renderowane w kilku etapach. 
Jego statyczne parametry opisuje plik tekstowy w specjalnym formacie. Pierwszy 
składnik nieba to tło, rysowane jako hemisfera. Jest ona pokryta gradientem — płyn¬ 
nym przejściem od koloru horyzontu do koloru zenitu. Dodatkowo w nocy przedsta¬ 
wiana jest na niej tekstura gwiazd. Datą i czasem steruje parametr Time, w którym 
jedna jednostka to jedna doba. 0 oznacza północ, 0.5 południe, 1 północ następnego 
dnia itd. Kolorami horyzontu i zenitu, interpolowanymi zależnie od pory dnia, steruje 
część pliku z opisem nieba taka jak w przykładzie: 
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Background { 

0.0 0x282B24 0x060606, 
0.3 0x282B24 0x060606, 
0.4 0xB8454A 0x5783C2, 
0.5 0x7f91a7 0x99CCF9, 
0.8 0xD0D3FE 0xl01F5A, 
0.9 0xED712B 0x001C43 

} 


// noc - czarno 
// noc - czarno 
// rano - wschód słońca 
// południe - jasno 
// popołudnie - błękit 
// wieczór - zachód słońca 


Drugi składnik nieba to chmury generowane proceduralnie za pomocą szumu Per- 
lina |49| . Przybliżenie szumu Perlina generowanego w czasie rzeczywistym na GPU 
zostało zrealizowane poprzez czterokrotne próbkowanie tekstury zwykłego szumu. 
Każde próbkowanie odbywa się z odpowiednio przeskalowanymi współrzędnymi tek¬ 
stury, a ich wyniki są sumowane z wagami tak, aby odpowiadać oktawom szumu Per¬ 
lina. Następnie wynik podlega dodatkowym przekształceniom, m.in. funkcją wykład¬ 
niczą. Chmura jest widoczna tylko w tych miejscach, w których wynik końcowy ma 
wartość powyżej określonej granicy. Granicę tą, jak również „ostrość” chmur można 
regulować w czasie działania, co pozwala płynnie zmieniać chmury np. stosownie do 
ogólnie pojętej pogody, wpływającej również na jasność oświetlenia czy intensywność 
opadów. Dodatkowo, kolor chmury jest interpolowany między dwoma podanymi kolo¬ 
rami zależnie od tej wartości intensywności w danym miejscu, co w pewnym stopniu 
imituje wrażenie przestrzenności chmur. Cały ten proces zilustrowany został na rys. 

[MS 



Rys. 3.21. Proces generowania chmur jako szum Perlina wyliczany w czasie rzeczywistym na 

GPU. 


Trzecim składnikiem nieba są ciała niebieskie — np. Słońce, Księżyc, duże gwiazdy 
czy planety. Są one opisywane przez strukturę CELESTIAL_OB JECT_DESC. Każde ciało 
niebieskie jest rysowane jako kwadrat pokryty wybraną teksturą. Jego ruch opisuje 
orbita, po jakiej obraca się wokół kamery. Podany musi zostać wektor normalny tej 
orbity, a także okres i faza obiegu. Ponadto istnieje możliwość modyfikowania koloru. 
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w jakim rysowana jest tekstura ciała niebieskiego (wraz z przezroczystością w kanale 
Alfa) zależnie od pory dnia i/lub od wysokości na niebie. Klasa renderująca niebo 
wieloetapowo buforuje pośrednie wyniki obliczeń, aktualizując je tylko przy pierwszym 
użyciu po zmianie danych wejściowych. Obliczanie pozycji wierzchołków ąuada ciała 
niebieskiego można przedstawić w pseudokodzie następująco (Time to aktualny czas, 
Desc to struktura opisująca orbitę po której krąży ciało niebieskie): 


// ComplexSky_pimpl::EnsureCelestialObjectDir 

vec3 RightDir = normalize(cross(vec3(0, 1, 0), Desc.OrbitNormal)) 
vec3 UpDir = normalize(cross(Desc.OrbitNormal, RightDir)) 
float Angle = Time * (2*PI / Desc.Period) + Desc.Phase 
vec3 Dir = cos(Angle) * RightDir + sin(Angle) * UpDir 


// ComplexSky. 
vec3 Forward 
vec3 Right = 
vec3 Up = ero 
matrix RotMat 
float Delta = 
Vertices[0] = 
Vertices[1] = 
Vertices [ 2 ] = 
Vertices[3] = 
Vertices[0] = 
Vertices[1] = 
Vertices[2] = 
Yertices[3] = 


_pimpl::FillQuadVerti 
= Dir 

Desc.OrbitNormal 
ss (Forward, Right) 

= AxesToMatrix(Right 
SKYDOME_RADIUS * tan 
vec3 (-Delta, -Delta, 
vec3 (-Delta, Delta, 
vec3 ( Delta, Delta, 
vec3 ( Delta, -Delta, 
Transform(Vertices[0 
Transform(Vertices[1 
Transform(Vertices[2 
Transform(Yertices[3 


ces 


, Up, Forward) 
(Desc.Size * 0.5) 
S KYD OME_RADIUS) 
SKYDOME_RADIUS) 

S KYD OME_RADIUS) 

S KYD OME_RADIU S) 

], RotMat); 

], RotMat); 

], RotMat); 

1, RotMat); 


3.11. Renderowanie drzew 


Drzewa są przez silnik renderowane w specjalny sposób, inaczej niż zwyczajne mo¬ 
dele. Kształt pnia, korzeni i gałęzi jest generowany proceduralnie. Autor opracował 
własny algorytm tego generowania, inspirowany (44], jednak znacznie prostszy. Pień, 
korzenie i gałęzie poziomu pierwszego mają siatkę o kształcie cylindrycznym, nato¬ 
miast mniejsze gałęzie są zbudowane z dwóch krzyżujących się czworokątów. Gałęzie 
powstają rekurencyjnie, a każdy poziom opisuje następująca struktura: 

struct TREE_LEVEL_DESC { 
bool Visible; 
uint SubbranchCount; 

float SubbranchRangeMin, SubbranchRangeMax; 

float SubbranchAngle, SubbranchAngleV; 

float Length, LengthV; 

float LengthToParent; 

float Radius, RadiusV; 

float RadiusEnd; 

float LeafCount, LeafCountV; 

float LeafRangeMin, LeafRangeMax; 


Pole SubbranchCount to liczba odgałęzień. Pola SubbranchRangeMin 
i SubbranchRangeMax wyznaczają procentowo zakres minimalnej i maksymalnej dłu¬ 
gości gałęzi, na której mogą pjawiać się podgałęzie. Kąt nachylenia odgałęzień wzglę¬ 
dem kierunku danej gałęzi jest liczbą losową o wartości SubbranchAnglei 
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SubbranchAngleV. Długość gałęzi danego poziomu jest liczbą losową o wartości 
Length±LengthV. Pole LengthToParent to dodatkowy składnik długości wyrażony 
w procentach długości gałęzi nadrzędnej. Grubość gałęzi (promień) wynosi 
Radius±RadiusV. RadiusEnd to promień zakończenia gałęzi, wyrażony w procentach 
promienia początkowego. Liczba liści osadzonych na gałęzi danego poziomu jest wy¬ 
rażona przez LeafCount±LeafCountV, a zakres procentowy długości gałęzi, na jakiej 
mogą się pojawiać liście, to 
LeafRangeMin.. .LeafRangeMax. 

Sposób renderowania liści wzorowany jest na obserwacji działania technologii Spe- 
edTree 1451 . Tekstura przedstawiająca grupę liści jest rysowana jako prostokąt zwró¬ 
cony zawsze przodem do kamery, o środku w punkcie leżącym w określonym miejscu 
na określonej gałęzi. Struktura wierzchołka używanego do renderowania drzew (za¬ 
równo pień, gałęzie, jak i liście są renderowane razem) wygląda następująco: 

struct TREE_VERTEX { 

VEC3 Pos; // Semantyka D3DFVF_XYZ 

VEC3 Normal; // Semantyka D3DFVF_N0RMAL 

COLOR Diffuse; // Semantyka D3DFVF_DIFFUSE 

VEC2 Tex; // Semantyka D3DFVF_TEXCOORDSIZE2(0) 

} ; 


Wykorzystanie składowych ARGB elementu Diffuse jest takie samo, jak w wierz¬ 
chołku używanym do renderowania trawy (p. 3.9) . Samo renderowanie też odbywa się 
w podobny sposób jak w przypadku trawy. Wierzchołki należące do liści są rozsuwane 
w kierunku „w prawo” i „do góry” pobranym z kamery tworząc czworobok zwrócony 
zawsze przodem do kamery. Ponadto są one przesuwane przez sumę ważoną dwóch 
współczynników wiatru, co daje wrażenie falowania liści na wietrze. 

Oświetlenie drzew również realizowane jest w sposób nietypowy. Jest ono obliczane 
zawsze metodą Half-Lambert, dzięki czemu drzewo widziane od strony przeciwnej niż 
źródło światła nie jest całkowicie czarne. Jako wektor normalny wierzchołków nale¬ 
żących do grup liści wpisany jest wektor wskazujący kierunek od środka drzewa do 
danej grupy liści. Dzięki temu grupy leżące w koronie drzewa po tej stronie, od której 
pada światło, są silniej oświetlone. 

Zrzut ekranu z tymczasowego edytora drzew, pokazujący przykładowy kształt ga¬ 


łęzi przed dodaniem liści, pokazuje rys. 3.22 


3.12. Renderowanie wody 


Powierzchnia wody renderowana jest w przedstawionym silniku jako płaszczyzna. 
Dlatego właściwie cały algorytm wizualizacji wody zawiera przeznaczony do tego celu 
Pixel Shader. Jego kod HLSL przedstawia poniższy listing: 
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L«vels[0] LeaTRangeMln - 1 00 Liczba rozgałęzień pnla 

Lcvols[0] LoafRangoMax « 1.10 

Levels[1] Visible - true 
Levels[1] SubbranchCount = 4 
Levels[1].SubbranchRangeMin ■ 0.00 

Levals[1].SubbranchRangeMax - 1.00 



Rys. 3.22. Tymczasowy edytor drzew. Przykładowy kształt gałęzi przed dodaniem liści. 


float3 DirToCam = normalize(In.VecToCam); 

DirToCam.y = abs(DirToCam.y); 

float3 NormalSamplel = 

tex2D(NormalSampler, In.NormalTexl).rgb *2-1; 
float3 NormalSample2 = 

tex2D(NormalSampler, In.NormalTex2).rgb *2-1; 
float3 FinalNormal = 

normalize(((NormalSamplel + NormalSample2)/2).xzy); 

float3 ReflectedLight = reflect (-DirToLight, FinalNormal); 
float3 ReflectedCam = reflect(-DirToCam, FinalNormal); 


float EnvFactor = ReflectedCam.y; 

float3 EnvColor = lerp (HorizonColor, ZenithColor, EnvFactor); 

float3 MyWaterColor = WaterColor; 

MyWaterColor += 

tex2D (CausticsSampler, In.CausticsTex) * CausticsColor; 

float FresnelFactor = 1 - saturate(dot(FinalNormal, DirToCam)); 
float3 FresnelColor = lerp(MyWaterColor, EnvColor, FresnelFactor); 

float SpecularFactor = pow(saturate(dot(ReflectedLight, DirToCam)), 
SpecularExponent); 

float3 SpecularColor = LightColor * SpecularFactor; 


Out.rgb = FresnelColor + SpecularColor; 

Out.a = lerp(WaterColor.a, 1, max(FresnelFactor, SpecularFactor)); 


Wyliczenie kolom powierzchni wody w danym miejscu składa się z kilku eta¬ 
pów. Pierwszym jest otrzymanie wektora normalnego, który symuluje pofalowaną 
powierzchnię wody. Powstaje on przez uśrednienie próbki z dwóch kopii mapy nor¬ 
malnych (patrz rys. |3.23 po lewej), przesuwanych w różnych kierunkach. Wektor 
FinalNormal jest wyrażony w układzie modelu. 

Następnie wyliczony zostaje wektor kierunku patrzenia kamery odbity od powierz¬ 
chni wody — ReflectedCam. Zostaje on wykorzystany do określenia koloru nieba 
EnvColor, jaki odbija się w wodzie w danym miejscu. Zastosowana w tym celu inter- 
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Rys. 3.23. Tekstury używane podczas renderowania wody. Po lewej: mapa normalnych. Po 

prawej: kaustyki. 


polacja od koloru horyzontu do koloru zenitu wg składowej y tego wektora jest prostym 
przybliżeniem mapowania środowiskowego, które mogłoby być w tym miejscu użyte, 
aby otrzymać prawdziwe odbicie w wodzie obrazu otaczającej ją sceny. 

Wartość MyWaterColor powstaje najpierw przez przypisanie stałej przechowującej 
kolor własny wody. Wbrew intuicji jest to kolor zielony, gdyż barwa niebieska pocho¬ 
dzi od odbicia nieba opisanego wyżej. Następnie dodawana jest do tej wartości próbka 


tekstury kaustyk (pokazanej na rys. 3.23 po prawej), pomnożona przez kolor kau- 
styk. Teoretycznie tekstura ta powinna być mapowana na dnie zbiornika, jednak dla 
uproszczenia jest adresowana jak na powierzchni wody. 

Wyliczany dalej współczynnik FresnelFactor przyjmuje wartości od 0, kiedy ka¬ 
mera patrzy prostopadle od góry na powierzchnię wody, do 1, kiedy kierunek patrzenia 
kamery jest równoległy do powierzchni wody w danym miejscu. Teoretycznie powinien 
on zostać podniesiony do potęgi, ale empirycznie stwierdzone zostało, że najlepszy wi¬ 
zualnie efekt daje wykładnik równy 1. Na podstawie tego współczynnika obliczony zo¬ 
staje końcowy kolor wody FresnelColor jako interpolacja między kolorem własnym 
wody a kolorem nieba odbitego od jej powierzchni. 

Dalej obliczony zostaje metodą Phonga Il4j odblask od źródła światła — 
SpecularColor. Jest to najbardziej efektowny składnik całego efektu wody. Jego 
kolor zostaje dodany do koloru końcowego. 

Stopień przezroczystości (kanał Alfa) również jest zależny od kąta nachylenia kie¬ 
runku patrzenia kamery do powierzchni wody w danym miejscu. Dzięki temu, spoglą¬ 
dając na wodę od góry, użytkownik widzi dno, kaustyki i kolor wody (zielony). Kiedy 
natomiast spogląda na powierzchnię wody od boku, widzi wodę o barwie niebieskiej, 
pochodzącej od odbicia nieba. To daje stosunkowo realistyczny efekt wymagając przy 
tym niewielkiej złożoności obliczeniowej. 


3.13. Implementacja swobodnego drzewa ósemkowego 

Ponieważ silnik przeznaczony jest do pokazywania scen zarówno typu otwartego, jak 
i zamkniętego, jako technikę podziału przestrzeni autor wybrał rozwiązanie, które do- 
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brze sprawdza się w obydwu tych zastosowaniach — swobodne drzewo ósemkowe II11 . 
Polega ono na rekurencyjnym podziale prostopadłościanu otaczającego cały wirtualny 
świat na 8 mniejszych prostopadłościanów. Wskaźnik do każdej encji utworzonej na 
scenie znajduje się na liście encji w jednym z węzłów drzewa, zagnieżdżonym tak 
głęboko, jak to możliwe, o ile sfera otaczająca tą encję mieści się w całości w pro¬ 
stopadłościanie opisującym granice danego węzła drzewa. Hierarchia węzłów drzewa 
ósemkowego nie ma przy tym nic wspólnego z hierarchią, jaką mogą tworzyć encje, 
aby ich przekształcenia były składane. Poniższy listing przedstawia definicję struk¬ 
tury węzła drzewa (język C++): 


struct ENTITY_OCTREE_NODE { 

BOX Bounds; 

ENTITY_OCTREE_NODE *Parent; 

ENTITY_OCTREE_NODE *SubNodes[8]; 
ENTITY_VECTOR Entities; 


Dokładny opis techniki drzew ósemkowych nie leży w zakresie niniejszej pracy. Zi¬ 
lustrowania wymaga jedynie modyfikacja kształu prostopadłościanów określających 
węzły względem węzła nadrzędnego, jakiej autor dokonał w stosunku do algorytmu 
zaproponowanego w 1 1 ll . Opiera się ona na obserwacji, że obiekty znajdujące się 
w danym węźle drzewa na pewno zawierają się w całości w jego AABB, więc wykracza¬ 
nie AABB węzłów podrzędnych poza obszar AABB węzła nadrzędnego nie ma sensu. 


Ilustruje to rys. 3.24 



a) b) c) 

Rys. 3.24. Kształt AABB podwęzłów drzewa ósemkowego względem AABB węzła 
nadrzędnego, w przekroju 2D. a) Zwykłe drzewo ósemkowe, b) Swobodne drzewo ósemkowe 
wg im c) Swobodne drzewo ósemkowe w implementacji autora. 


Drzewo reprezentuje klasa EntityOctree, będąca częścią implementacji wewnętrz¬ 
nej silnika, niewidocznej dla użytkownika. Scena używa jej do przechowywania encji. 
Ponieważ encje mogą być tworzone i usuwanie w czasie działania, a także zmieniać 
swoje parametry, zachodzi potrzeba dynamicznej reorganizacji drzewa — łączenia lub 
dzielenia węzłów. Metoda dodająca encję do drzewa to AddEntityToNode. Jej algo¬ 
rytm można przedstawić w pseudokodzie następująco: 
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"function AddEntityToNode(Węzeł, Encja)" 
if (Węzeł nie jest liściem): 

foreach (Podwęzeł in Węzeł.Podwęzły): 

if (Encja.Sfera_otaczająca zawiera się w Podwęzeł.AABB): 
AddEntityToNode(Podwęzeł, Encja) // Rekurencja 
return 

Węzeł.Dodaj_encję(Encja) 
else: 

Węzeł.Dodaj_encję(Encja) 

if (Węzeł.Liczba_encji > ENTITY_OCTREE_SPLIT_ENTITY_COUNT): 
SplitNode(Węzeł) 

Metoda ta próbuje dodać encję do węzła tak głęboko zagnieżdżonego, jak to moż¬ 
liwe. Jeśli sfera otaczająca tą encję nie zawiera się w całości w prostopadłościanie 
otaczającym żadnego z podwęzłów, encja trafia do węzła aktualnego (encje mogą być 
zawarte nie tylko w liściach, ale w dowolnych węzłach drzewa). Jeśli dany węzeł nie 
posiada podwęzłów, ale po dodaniu do niego nowej encji liczba wszystkich encji na 
jego liście przekroczyła granicę określoną przez stałą, wywołana zostaje metoda dzie¬ 
ląca węzeł na podwęzły. Jej algorytm w pseudokodzie to: 

"function SplitNode(Węzeł)" 

box AABB[8] = BuildSubBounds(Węzeł.AABB) 

for (i = 0. . 7) : 

Węzeł.Podwęzły [i] = lnicjalizuj_węzeł(AABB[i]) 
foreach (Encja in Węzeł.Encje): 

foreach (Podwęzeł in Węzeł.Podwęzły): 

if (Encja.Sfera_otaczająca zawiera się w Podwęzeł.AABB): 

Podwęzeł.Encje.Dodaj(Encja) 

Węzeł.Encje.Usuń(Encja) 
break 


Metoda ta tworzy i inicjalizuje 8 podwęzłów dla podanego węzła. Ich alokacja od¬ 
bywa się z użyciem szybkiego alokatora FreeList (p. 2.3} . Metoda BuildSubBounds 
użyta zostaje w celu wyliczenia parametrów prostopadłościanów otaczających podwę¬ 
zły na podstawie przekazanego prosopadłościanu węzła. Dalej algorytm przechodzi 
kolekcję encji zapamiętanych w węźle i każdy z nich próbuje przenieść do pierwszego 
z podwęzłów, w którym sfera otaczająca encji mieści się w całości. 

Reorganizacja drzewa potrzebna jest także podczas usuwania encji. Odpowiada 
za to metoda RemoveEntity. Jej algorytm w pseudokodzie przedstawia następujący 
listing: 


"function RemoveEntity(Encja)" 

Węzeł = Encja.Węzeł_w_którym_leży 
Węzeł.Encje.Usuń(Encja) 
if (Węzeł nie jest korzeniem): 

TryJoin(Węzeł.Węzeł_nadrzędny) 

Każda encja ma zapamiętany węzeł drzewa ósemkowego, w którym leży. Na jego 
podstawie metoda lokalizuje encję na liście tego węzła i usuwają z tej listy. Ponieważ 
usunięcie encji może być okazją do połączenia węzła, w którym leżała, z jego rodzeń¬ 
stwem, wywołana zostaje metoda TryJoin dla węzła nadrzędnego. 
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"function TryJoin(Węzeł)" 

uint LiczbaEncji = Węzeł.Encje.Liczba 

foreach (Podwęzeł in Węzeł.Podwęzły): 

if (Podwęzeł nie jest liściem): 
return 

LiczbaEncji = LiczbaEncji + Podwęzeł.Encje.Liczba 
if (LiczbaEncji < ENTITY_OCTREE_JOIN_ENTITY_COUNT): 

foreach (Podwęzeł in Węzeł.Podwęzły): 
foreach (Encja in Podwęzeł.Encje): 

Węzeł.Encje.Dodaj(Encja) 

Usuń Podwęzeł 

Powyższa metoda najpierw zlicza liczbę encji zawartych w podanym węźle oraz w 
jego podwęzłach. Sprawdza przy okazji, czy wszystkie jego podwęzły są liśćmi. Jeśli 
nie są (mają swoje podwęzły), to podany węzeł nie nadaje się do połączenia i cały 
algorytm zostaje przerwany. Jeśli wynikowa liczba encji jest poniżej progu określonego 
stałą, algorytm łączy przekazany mu węzeł. W tym celu najpierw przepisuje wszystkie 
encje z list swoich podwęzłów do swojej listy, a następnie usuwa swoje podwęzły. 

Trzecim przypadkiem jest sytuacja, kiedy w istniejącej encji zmieniają się para¬ 
metry kształtu jej sfery otaczającej — tj. jej pozycja lub promień. Zostaje wówczas 
wywołana metoda drzewa ósemkowego OnEntityParamsChange. Oto jej algorytm 
w pseudokodzie: 

"function OnEntityParamsChange (Encja)" 

Węzeł = Encja.Węzeł_w_którym_leży 

if (Encja.Sfera_otaczająca zawiera się w Węzeł.AABB): 

if (Węzeł nie jest liściem): 

foreach (Podwęzeł in Węzeł.Podwęzły): 

if (Encja.Sfera_otaczająca zawiera się w Podwęzeł.AABB): 

Węzeł.Encje.Usuń(Encja) 

AddEntityToNode(Podwęzeł, Encja) 
break 

else: 

NowyWęzeł = Węzeł 

Pętla: 

if (NowyWęzeł jest korzeniem): 
break 

NowyWęzeł = NowyWęzeł.Węzeł_nadrzędny 

if (Encja.Sfera_otaczająca zawiera się w NowyWęzeł.AABB): 
break 

RemoveEntity(Encja) 

AddEntityToNode(NowyWęzeł, Encja) 

Powyższa metoda korzysta z wcześniej przedstawionych, aby zaktualizować węzeł, 
w którym zawiera się zmieniona encja, a przy okazji wykonać wymaganą reorganizację 
drzewa. Rozpatruje ona dwa główne przypadki. Pierwszy to sytuacja, kiedy sfera ota¬ 
czająca zmienioną encję nadal zawiera się w węźle, w którym encja dotychczas leżała. 
Wówczas jedyne co można zrobić to sprawdzić, czy po zmianie parametrów encja nie 
zaczęła mieścić się w całości w jednym z podwęzłów. Jeśli tak jest, zostaje ona usu¬ 
nięta ze swojego węzła i dodana do określonego podwęzła metodą AddEntityToNode. 
Drugi przypadek to sytuacja, kiedy zmieniona encja przestała mieścić się w AABB swo¬ 
jego węzła. Wówczas pętla przechodzi ścieżkę w górę drzewa poszukując najniższego 
z węzłów, w którym jej nowa sfera otaczająca się zawiera. Kiedy taki węzeł zostaje 
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znaleziony, encja jest usuwana z listy swojego starego węzła i dodawana do drzewa 
na poziomie znalezionego węzła metodą AddEntityToNode. Trzeba podkreślić, że me¬ 
toda ta wykona rekurencyjne przejście w dół drzewa celem znalezienia najbardziej 
zagnieżdżonego węzła, do którego encja może trafić. 

Korzystanie z drzewa polega na zadawaniu zapytań, których celem jest zwrócenie 
zbioru encji potencjalnie przecinających podany obiekt geometryczny. Dzięki struk¬ 
turze hierarchicznej wyszukiwanie to odbywa się z szybkim eliminowaniem całych ga¬ 
łęzi (zawierających duże grupy encji). Można to porównać do logarytmicznego czasu, 
w jakim wykonuje się algorytm wyszukiwania binarnego w tablicy jednowymiarowej. 
Zależnie od sytuacji zachodzi potrzeba zadawania różnych zapytań. Służą do tego me¬ 
tody publiczne drzewa: FindEntities_Frustum pytająca o listę encji przecinających 
frustum, FindEntities_SpotLight pytająca o listę encji w zasięgu podanego światła 
latarki, FindEntities_PointLight pytająca o listę encji w zasięgu podanego świa¬ 
tła punktowego, FindEntities_DirectionalLight pytająca o listę encji rzucających 
cień na obszar widoczny w kamerze w kierunku padania podanego światła kierunko¬ 
wego oraz RayCollision sprawdzająca kolizję promienia z encjami. Poniższy listing 
przedstawia w pseudokodzie algorytm pierwszej z nich. Implementacja pozostałych 
wygląda podobnie. 


"function FindEntities_Frustum(Frustum, out Encje)" 
FindEntities_Frustum_Node(Korzeń, Frustum, Encje, false) 

"function FindEntities_Frustum_Node(Węzeł, Frustum, out Encje, 
Wewnątrz)" 

if (Węzeł nie jest liściem): 

foreach (Podwęzeł in Węzeł.Podwęzły): 
if (Wewnątrz): 

FindEntities_Frustum_Node(Podwęzeł, Frustum, Encje, true) 
else if (Podwęzeł.AABB zawiera się w Frustum): 

FindEntities_Frustum_Node(Podwęzeł, Frustum, Encje, true) 
else if (Podwęzeł.AABB przecina Frustum): 

FindEntities_Frustum_Node(Podwęzeł, Frustum, Encje, false) 
foreach (Encja in Węzeł.Encje): 
if (Encja.Widoczna) : 

if (Wewnątrz lub Encja. Sfera_otaczaja.ca przecina Frustum): 
Encje.Dodaj(Encja) 


Rekurencyjna metoda FindEntities_Frustum_Node składa się z dwóch etapów. 
Pierwszy to przechodzenie podwęzłów. Drugi to sprawdzenie encji zawartych w danym 
węźle. Na uwagę zasługuje tu parametr typu logicznego Wewnątrz, który służy do 
optymalizacji wydajności. Kiedy stwierdzone zostaje, że AABB pewnego węzła drzewa 
zawiera się w całości wewnątrz przekazanego frustuma, wówczas Wewnątrz przyjmuje 
wartość true. To sygnalizuje, że wszystkie podwęzły, jak również wszystkie encje 
leżące w danym węźle i jego podwęzłach na pewno przecinają frustum i nie trzeba ich 
już testować. Tylko kiedy AABB węzła przecina frustum, ale nie zawiera się w nim 
w całości. Wewnątrz ma wartość false i wtedy potrzebne jest testowanie przecięcia 
z frustumem sfer otaczających encje oraz AABB podwęzłów. 
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3.14. Budowa mapy 


Mianem mapy w opisywanym silniku określana jest geometria przedstawiająca ściany, 
podłogi, sufity, korytarze, pomieszczenia, schody itp., wewnątrz których porusza się 
użytkownik w scenach typu zamkniętego. W tym sensie mapa przypomina siatki 
modeli, ale jednak nie może być traktowana w ten sam sposób. 

W każdej chwili widoczny jest tylko niewielki fragment mapy. Dlatego zachodzi po¬ 
trzeba zastosowania podziału przestrzeni, który pozwoli szybko odrzucać niewidoczne 
fragmenty geometrii. Autor ponownie zastosował w tym celu swobodne drzewo ósem¬ 
kowe. Ponieważ mapa składa się z trójkątów, a ponadto pozostaje niezmienna przez 
cały czas działania programu, przechowywanie fragmentów mapy w jednym drzewie 
z encjami nie jest dobrym pomysłem. Dlatego mapa jest osobnym typem obiektu 
w silniku i posiada własny kod do realizacji wszystkich tych zadań. 

Specjalna wtyczka do programu graficznego Blender napisana w języku Python 
eksportuje scenę do tekstowego formatu pośredniego z myślą o przetworzeniu na 
mapę. Wtyczka ta znajduje się w pliku TFQ_QMAP_TMP_Exporter . py. Narzędzie kon¬ 
solowe Tools przetwarza plik w formacie QMSH.TMP do binarnego formatu docelowego 
QMAP. Format ten jest następnie wczytywany przez klasę QMap silnika, która udostęp¬ 
nia do odczytu dane. Wreszcie, dane te są wykorzystywane przez klasę QMapRenderer 
do wyświetlania mapy jako część sceny. 

Autor postanowił nie opisywać dokładnie w niniejszej pracy formatu pliku QMAP, 
ponieważ nie jest to format ostateczny. W prawdziwych zastosowaniach mapa, oprócz 
geometrii ścian, podłóg itp., musi zawierać także dane na temat świateł i różnego ro¬ 
dzaju encji — ich pozycji i parametrów. Na przykład w przypadku gry z gatunku FPS 
mogłyby to być wrogie potwory, broń, paczki z amunicją, apteczki i przyciski otwiera¬ 
jące drzwi. Wstawianie takich encji można sobie wyobrazić w programie graficznym 
typu Blender jako obiekty puste (typu Empty) lub specjalnie oznaczone, proste siatki 
jak prostopadłościan. Jednak lepiej byłoby używać w tym celu specjalnego edytora 
map takiego jak QuArK, DeleD lub własnego edytora napisanego specjalnie na po¬ 
trzeby danej gry. Dane, jakie powinna przechowywać mapa, silnie zależą od konkret¬ 
nego zastosowania, dlatego nie sposób przewidzieć ich pisząc ogólny silnik graficzny. 

Geometria mapy zapisana jest w pliku i wczytywana do pamięci w formie swobod¬ 
nego drzewa ósemkowego, a jego węzły są alokowane za pomocą szybkiego alokatora 
FreeList (p. 2.3) — tak jak ma to miejsce w przypadku drzewa encji opisanego w po¬ 
przednim podrozdziale. W mapie jednak węzły drzewa przechowują fragmenty geo¬ 
metrii, a więc trójkąty. Cała mapa występuje w dwóch kopiach, każda w osobnym 
drzewie ósemkowym. 

Kopia pierwsza jest przeznaczona do renderowania. Wierzchołki i indeksy zapamię¬ 
tane są w buforach w pamięci karty graficznej. Wierzchołki posiadają pełne informa¬ 
cje, łącznie ze współrzędnymi tekstury, wektorem normalnym i wektorami stycznymi. 
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Drzewo jest słabo rozdrobnione, aby w każdym węźle zawarta była niezbyt mała porcja 
geometrii. To zapewnia szybsze renderowanie. Fragmenty geometrii pamiętane przez 
każdy z węzłów pogrupowane są według używanego materiału. 

Druga kopia mapy przeznaczona jest do liczenia kolizji. Jej wierzchołki zawierają 
wyłącznie pozycję (w celu bardziej zaawansowanych obliczeń kolizji należałoby dodać 
także wektory normalne) i są pamiętane w tablicy w pamięci systemowej. Drzewo 
ósemkowe jest rozdrobnione, tak aby jak najwięcej trójkątów odrzucać bez dokładnego 
testowania. 
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Rozdział 4 


Przykłady 


Niniejszy rozdział zawiera kolorowe zrzuty ekranu, które pokazują efekt działania 
systemu omówionego w tej pracy. Warto podkreślić, że wszystkie przedstawione tu 
zrzuty ekranu zostały wyrenderowane w czasie rzeczywistym przez program opisany 
w niniejszej pracy, stworzony przez autora. 

4.1. Przykłady gier komputerowych 

Ponieważ silnik jest biblioteką, konieczne było napisanie programu „klienta”, który 
będzie stanowił namiastkę prawdziwego kodu wykorzystującego taką bibliotekę. Kod 
zgromadzony w katalogu Client stanowią proste prototypy 5 gier różnego gatunku. 
Zostały one tak pomyślane, aby pokazać wszystkie efekty graficzne oferowane przez 
silnik, a zarazem w efektowny sposób zaprezentować jego potencjalne zastosowania. 
Są to: 

GamePacman — gra typu Pacman. Grafika jest prosta, kolorowa. Cienie są wy¬ 
łączone. Prezentuje możliwości materiałów na przykładzie błyszczących kryształków 
i półprzezroczystych duchów, a także efekty cząsteczkowe. Patrz rys. |4.1[ 

GameRts to gra typu RTS fang. Real-Time Strategy — strategia czasu rzeczywi¬ 
stego). Prezentuje teren z drzewami, trawą i wodą w widoku od góry. Modele rycerzy 
używają mechanizmu Team Color, aby zmieniać kolor niektórych części tekstury za¬ 
leżnie od drużyny do której należą, a także podlegają animacji szkieletowej. Patrz rys. 

E3 
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Rys. 4.1. Przykładowa gra nr 1 typu Pacman. 



Rys. 4.2. Przykładowa gra nr 2 typu RTS (ang. Real-Time Strategy — strategia czasu 

rzeczywistego). 


GameSpace to gra polegająca na sterowaniu statkiem kosmicznym latającym nad 
powierzchnią obcej planety. Pokazana jest w niej przestrzeń otwarta, wykorzystana 
do renderowania krajobrazu pozaziemskiego. Teren stanowią brązowe skały i kratery, 
a na niebie widoczne są brązowe chmury i odległa planeta. Broń stosowana przez sta¬ 
tek gracza i przeciwnika wykorzystuje efekty cząsteczkowe i promienie (wstęgi). Moż¬ 
liwość celowania prezentuje obliczanie kolizji promienia z obiektami sceny oferowane 
przez silnik. Ponadto gra wykorzystuje efekt sprzężenia zwrotnego do zasymulowania 
prostego rozmycia ruchu (ang. MotionBlur). Sztuczna inteligencja statku przeciwnika 


oparta została na logice rozmytej. Patrz rys. 4.3 
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Rys. 4.3. Przykładowa gra nr 3, polegająca na sterowaniu statkiem kosmicznym latającym 

nad powierzchnią obcej planety. 


GameFpp to gra typu FPS (ang. First Person Shooter — strzelanka z perspektywy 
pierwszej osoby). Jako jedyna z przykładowych gier wykorzystuje jako otocznie mapę 
zamkniętą wczytaną z pliku QMAP. Ważną rolę odgrywają w niej dynamiczne oświe¬ 


tlenie i cienie, a także nakładany na powierzchnie Normal Mapping. Patrz rys. 4.4 



Rys. 4.4. Przykładowa gra nr 4 typu FPS (ang. First Person Shooter — strzelanka z 

perspektywy pierwszej osoby. 


GameRpg to najbardziej zaawansowana z gier. Ma w założeniu symulować śro¬ 
dowisko gier typu MMORPG (ang. Masswely Multiplayer Online Role-Playing Gamę). 
Środowisko gry stanowi teren otwarty o dużej powierzchni, widziany z perspektywy 
trzeciej osoby (TPP - ang. Third Person Perspective). Model bohaterki jest animowany, 
a do przełączania animacji stania i chodzenia pod wpływem sterowania z klawiatury 
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wykorzystywane jest płynne przejście. Gra prezentuje wszelkie dostępne efekty prze¬ 


strzeni otwartych (woda, drzewa, trawa, opady deszczu i śniegu, falowanie roślin na 


silnym wietrze, niebo z chmurami), a także efekty cząsteczkowe i inne. Patrz rys. 4.5 



Rys. 4.5. Przykładowa gra nr 5, mająca symulować środowiko gier typu MMORPG. 


4.2. Przykłady efektów graficznych 


Rys. |4.6| powstał w celu zilustrowania parametrów sterujących zachowaniem encji 


typu QuadEntity. 



Rys. 4.6. Ułożenie ąuadów zależnie od parametrów obiektu klasy 

engine::BillboardEntity. 
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Rys. |4.7| zawiera przykłady pokazujące możliwości encji typu StripeEntity. Rys. 
|4.8| pokazuje inny typ encji przydatny do tworzenia efektów specjalnych — efekt czą¬ 
steczkowy. 



Rys. 4.7. Przykładowy wygląd różnego rodzaju „pasków” typu engine: : StripeEntity. 



Rys. 4.8. Złożenie 5 encji efektów cząsteczkowych klasy engine : : ParticleEntity dla 
zaprezentowania 3 przykładów zastosowania — magiczne cząsteczki, chmura z deszczem 

oraz ogień i dym. 
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Rys. |4.9| pokazuje niebo nocą, wyraźnie ilustrując kształt generowanych procedu¬ 
ralnie chmur. Rys. |4.10| pokazuje teren, wyrenderowany dla czytelności bez żadnych 
dodatkowych obiektów na jego powierzchni. 


BBS 

Day 0 (0:0) 


Framework: FP3«137.148, Draws*24. Prlmltlv*s"14586 
ResMngr: Resourc«s»94. Loaded*23. Locked«12 

Engine: Optlmlzer*-EL. Passes"4, SpotLlghts«0:0, PolntLlgh!s«0:0 EntItles—0:0. MapFiagmenls"0, T«iralnPatehas"4, MalnShad»rs«7, PpShaders*0 
DłbugSlrlng- 



Rys. 4.9. Niebo nocą jako przykład renderowania proceduralnie generowanych chmur. 


BBS 


Framework: FP3«133.259, Draws»33, Prlmltlves«36946 
ResMngr: Resources>83. Loaded<*15, Locked«6 

Engine: Optlmlzer»-EL, Passes«4, SpotLlghts«0:0, PolntLlgMs«0:0 Entltles«0:0, MapFragments«0. TerialnPatclies«10. MalnShader**5. Pp3haders"0 
DebugStrlng* 


■ The Finał Quest 



Rys. 4.10. Przykładowy teren. Widoczne przejście między formami terenu zależne od 
wysokości (piasek, trawa, śnieg), jak również wyznaczone przez projektanta (ścieżka). 
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Rys. 4.11 pokazuje wygląd wody z widocznym odblaskiem od Słońca. Rys. 4.12 
pokazuje fragment terenu pokryty drzewami i trawą. 



Rys. 4.11. Przykład renderowania wody z widocznym odblaskiem od światła kierunkowego. 



Rys. 4.12. Przykład renderowania przestrzeni otwartych. Widoczny teren, niebo, drzewa oraz 

trawa. 
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Rys. |4.13| pokazuje efekt opadów atmosferycznych na przykładzie zamieci śnieżnej. 
Rys. |4.14| pokazuje przykład nietypowego materiału, jaki można uzyskać manipulując 
parametrami klasy materiału. 



Rys. 4.13. Zamieć śnieżna jako przykład renderowania efektów atmosferycznych. 



Rys. 4.14. Przykład zastosowania mapowania środowiskowego z użyciem specjalnie 
przygotowanej tekstury sześciennej wraz z półprzezroczystością i Fresnel Term do otrzymania 

nietypowego materiału. 
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Rys. 4.15 pokazuje efekt błysku soczewek nakładany w sposób dwuwymiarowy 
na obraz sceny. 



Rys. 4.15. Efekt błysku soczewek pomaga w efektowny sposób przedstawić Słońce. 
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Rozdział 5 


Podsumowanie 


W ramach pracy stworzony został silnik grafiki trójwymiarowej. Jego kod posłużył 
jako przykład do opisania architektury i implementacji takiego silnika. Nie może on 
oczywiście dorównać możliwościami ani jakością silnikom rozwijanym przez wiele lat 
i przez wielu ludzi, jakie dostępne są na rynku. Stanowi jednak możliwie efektowny, 
kompletny oraz — co bardzo ważne — ukończony projekt, który może teoretycznie 
znaleźć zastosowanie przy tworzeniu gier komputerowych i nie tylko. 


Kod silnika dołączony do niniejszej pracy na płycie CD był pisany przez jedną 
osobę (autora) przez około pół roku. Liczy ponad 84 tys. linii. Do jego stworzenia 
potrzebne były wiedza, doświadczenie i fragmenty kodu wypracowane przez autora 
w toku wieloletniej nauki programowania. Cały silnik, jak również wersja binarna 
programu demonstracyjnego, zrzuty ekranu i materiały video udostępnione są rów¬ 
nież na stronie internetowej autora — http: //regedit .gamedev.pl. Silnik można 
pobrać wraz z kodem źródłowym na licencji GNU GPL. Implementacja, jakkolwiek nie 
wprowadza żadnego poważnego nowego rozwiązania, zawiera wiele nowatorskich po¬ 
mysłów autora — np. progresywny dysk Poissona (p. |2.3 czy sposób realizacji efektu 
opadów atmosferycznych (p. |3.8). 


Pośród trudności, jakie powstały podczas pisania kodu silnika wymienić należy na 
pierwszym miejscu implementację poszczególnych efektów graficznych. Samo zrozu¬ 
mienie i zamodelowanie danego efektu to jednak dopiero połowa pracy. Nie mniej 
wysiłku kosztowało zintegrowanie danego efektu z resztą silnika tak, aby stał się 
na przykład jedną z właściwości materiału czy jednym z efektów postprocessingu. 
Trudne było zapanowanie nad kodem shadera głównego, który wydłużał się bardzo 
szybko i ze względu na budowę według modelu subtraktywnego był trudny w po¬ 
prawianiu i konserwacji. Zorganizowanie procesu renderowania poszczególnych ele¬ 
mentów sceny w sposób wydajny trudne było do pogodzenia z chęcią zapewnienia 
prostoty i elegancji kodu oraz zachowania zasad programowania obiektowego. Uży¬ 
cie własnego formatu siatek — QMSH — wymagało napisania wtyczki eksportującej 
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do programu graficznego Blender, a do tego z kolei konieczne było opanowanie w do¬ 
brym stopniu zarówno języka skryptowego Python, jak i obsługi programu graficznego 
Blender i API, jakie udostępnia dla wtyczek pisanych w tym języku. Wreszcie, spośród 
mechanizmów silnika najtrudniejsze okazało się chyba opracowanie algorytmu zapi¬ 
sywania, przeliczania i renderowania siatek korzystających z animacji szkieletowej, 
a także renderowanie cieni. 

Możliwości rozbudowy Opisany w niniejszej pracy silnik graficzny został uznany 
za ukończony. Autor zdaje sobie jednak sprawę z licznych ograniczeń, jakie posiada 
ta praca i z istnienia technik i efektów, które byłyby pożądane, a które nie zostały 
zaimplementowane z powodu ograniczeń czasowych i innych. 

Pośród efektów graficznych brakuje na przykład refleksji, czyli wszelkich odbić, 
które pozwalałaby na renderowanie luster, powierzchni wody odbijającej krajobraz 
na horyzoncie czy powierzchni metalicznych. Do przedstawienia materiałów takich 
jak cegły przydałaby się technika mapowania nierówności bardziej zaawansowana, 
niż zaimplementowany tu Normal Mapping — np. Parallax Mapping czy Cone Step 
Mapping. 

Pewnym ograniczeniem jest oddzielne traktowanie niektórych rodzajów obiektów, 
np. terenu, drzew, trawy, które uniemożliwia zastosowanie do nich pełnej gamy do¬ 
stępnych efektów materiału i oświetlenia. Przydałby się na przykład Normal Mapping 
terenu i kory drzew albo rzucanie i otrzymywanie cienia przez trawę. Dużym ograni¬ 
czeniem może też być fakt, że materiały półprzezroczyste są zupełnie osobną kategorią 
materiałów i nie podlegają oświetleniu, ponieważ z tego powodu normalne obiekty nie 
mogą płynnie pojawiać się i znikać. 

Zastosowanie LOD do różnych elementów silnika znacznie poprawiłoby wydajność 
lub pozwoliłoby na renderowanie większej liczby obiektów. Obecnie poziom szczegóło¬ 
wości jest dynamicznie wybierany jedynie dla terenu, efektów cząsteczkowych i trawy. 
Możnaby zastosować tą technikę także do siatek modeli, do drzew, a nawet do mate¬ 
riałów (powierzchnie oddalone od kamery mogłyby być renderowane bez kosztownych 
obliczeniowo efektów). Do przełączania poziomów szczegółowości siatek — w tym mo¬ 
deli i terenu — powinna być zastosowana pewna forma CLOD. aby nie było widoczne 
„przeskakiwanie” między poszczególnymi poziomami. 

Uniwersalny silnik powinien być wyposażony w różne metody obliczania oświetle¬ 
nia i cieni. Opisany tutaj kod posiada wyłącznie oświetlenie dynamiczne i dynamiczne 
cienie renderowane metodą Shadow Mapping. Przydatne mogłoby być też oświetlenie 
statyczne [Lightmapping czy Radiositg Normal Mapping) , a także cienie renderowane 
drugą popularną metodą — Shadow Volume. Sam Shadow Mapping, w przypadku 
świateł kierunkowych i scen typu otwartego, powinien być wyposażony w rodzaj repa- 
rametryzacji poprawiających jakość cieni — np. LiSPSM, TSM lub XSM. 

Poprawić wydajność mógłby także inny rodzaj podziału przestrzeni. Zastosowane 
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w silniku swobodne drzewa ósemkowe są dobre i uniwersalne, ale w scenach typu 
zamkniętego lepiej sprawdziłyby się portale. W kwestii wydajności, sama organizacja 
procesu renderowania sceny również dałaby się pod pewnymi względami ulepszyć. 
Na przykład renderowanie mogłoby przyspieszać lepsze zarządzanie stanami urządze¬ 
nia Direct3D i stałymi przekazywanymi do shadera, tak aby nie były one wszystkie 
ustawiane przed renderowaniem każdej encji. 

Manager zasobów mógłby zostać przepisany w taki sposób, aby zasoby mogły być 
wczytywane asynchronicznie, w osobnym wątku. Wczytywanie danych z plików moż- 
naby uogólnić na pobieranie ich z dowolnego strumienia danych, co pozwoliłoby na 
przechowywanie danych programu w postaci spakowanej w VFS (ang. Virtual File 
System) czy też ich pobieranie prosto z Internetu. Obiekty zajmujących dużo pamięci, 
jak mapa czy teren, mogłyby być strumieniowane przechowując w pamięci tylko wy¬ 
brane fragmenty. Parametry wielu obiektów, np. mapa wysokości terenu, powinny 
móc zmieniać się dynamicznie podczas działania silnika bez konieczności ponow¬ 
nego tworzenia całego obiektu i wczytywania wszystkich danych z plików na dysku. 
W przypadku, gdyby w oparciu o ten silnik powstawał edytor, byłoby to koniecznością. 

W kwestii architektury trzeba przyznać, że silnik jest słabo rozszerzalny i uogól¬ 
niony. Trudno byłoby dopisać do niego nowy efekt materiałowy czy efekt postpro- 
cessingu. Częściowo wynika to założeń, zgodnie z którymi silnik ten ma być biblio¬ 
teką zamkniętą, ukrywającą szczegóły implementacyjne. Jednak organizację kodu 
możnaby poprawić w wielu miejscach, na przykład budując shader główny w sposób 
addytywny, a nie subtraktywny. 

Silnik jako biblioteka, aby mieć większą wartość w oczach potencjalnych użytkow¬ 
ników, mógłby zostać rozbudowany o dodatkowe narzędzia i inne materiały. Oprócz 
eksporterów do programu graficznego Blender przydałyby się eksportery do innych 
popularnych programów, np. 3ds Max, Maya, a także konwertery z różnych formatów 
modeli do formatu QMSH. Sam kod silnika wartoby skompilować do postaci pojedyn¬ 
czej biblioteki LIB lub DLL. tak aby był gotowy do użycia w programie. Wreszcie, aby 
zastosować go w poważnym projekcie, potrzebna byłaby dobra dokumentacja jego 
API, a także dodatkowe programy narzędziowe z graficznym interfejsem użytkownika 
(przede wszystkim edytory), zastępujące konieczność edytowania plików tekstowych 
w specjalnych formatach oraz tekstur narzędziowych przedstawiających na swoich 
pikselach np. rozmieszczenie drzew i trawy. Wypada też jeszcze raz powtórzyć, że opi¬ 
sany w tej pracy kod to jedynie silnik graficzny (renderer). Czym innym jest tzw. silnik 
gry, który oprócz możliwości graficznych implementuje także dźwięk, fizykę, sztuczną 
inteligencję i inne potrzebne funkcje. 
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